diff options
Diffstat (limited to 'man')
313 files changed, 73191 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..073174c --- /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..a4e5082 --- /dev/null +++ b/man/binfmt.d.xml @@ -0,0 +1,75 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..9cfa9cc --- /dev/null +++ b/man/bootctl.xml @@ -0,0 +1,154 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 the firmware and boot manager settings</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 boot loader status, list 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>Options</title> + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--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>/boot</filename>, if possible.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>-p</option></term> + <term><option>--print-path</option></term> + <listitem><para>This option modifies the behaviour of <command>status</command>. + Just print the path to the EFI System Partition (ESP) to standard output and + exit.</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> + + <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>Commands</title> + <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> + + <varlistentry> + <term><option>install</option></term> + + <listitem><para>Installs systemd-boot 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>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 the boot + loader.</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> + </varlistentry> + + </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>--path=</option> may refer to any kind of file system on any kind of + 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> + </para> + </refsect1> +</refentry> diff --git a/man/bootup.xml b/man/bootup.xml new file mode 100644 index 0000000..5f63fe7 --- /dev/null +++ b/man/bootup.xml @@ -0,0 +1,301 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 system + boot. Immediately after power-up, the system BIOS will do minimal + hardware initialization, and hand control over to a boot loader + stored on a persistent storage device. This boot loader will then + invoke an OS kernel from disk (or the network). In the Linux case, + this kernel (optionally) extracts and executes an initial RAM disk + image (initrd), such as generated by + <citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>, + which looks for the root file system (possibly using + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for this). 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 on the OS image, 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>local-fs-pre.target + | + v +(various mounts and (various swap (various cryptsetup + fsck services...) devices...) devices...) (various low-level (various low-level + | | | services: udevd, API VFS mounts: + v v v tmpfiles, random mqueue, configfs, + local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...) + | | | | | + \__________________|_________________ | ___________________|____________________/ + \|/ + v + sysinit.target + | + ____________________________________/|\________________________________________ + / | | | \ + | | | | | + v v | v v + (various (various | (various rescue.service + timers...) paths...) | sockets...) | + | | | | v + v v | v <emphasis>rescue.target</emphasis> + timers.target paths.target | sockets.target + | | | | + v \_________________ | ___________________/ + \|/ + v + basic.target + | + ____________________________________/| emergency.service + / | | | + | | | v + v v v <emphasis>emergency.target</emphasis> + display- (various system (various system + manager.service services services) + | required for | + | graphical UIs) v + | | <emphasis>multi-user.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>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>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>initd-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='die-net'><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..a5e3d92 --- /dev/null +++ b/man/busctl.xml @@ -0,0 +1,492 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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>--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> 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> + + <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="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>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>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>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..4ccc174 --- /dev/null +++ b/man/coredump.conf.xml @@ -0,0 +1,141 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + <literal>[Coredump]</literal> 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..94d5626 --- /dev/null +++ b/man/coredumpctl.xml @@ -0,0 +1,343 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> + will be used. </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>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 list 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><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>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 noindex="true">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..3574ce0 --- /dev/null +++ b/man/crypttab.xml @@ -0,0 +1,437 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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'> + + <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>name</replaceable> <replaceable>encrypted-device</replaceable> <replaceable>password</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 + block device; the device is set up within + <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 the encryption password. If the + field is not present or the password is set to + <literal>none</literal> or <literal>-</literal>, the password has + to be manually entered during system boot. Otherwise, the field is + interpreted as an absolute path to a file containing the encryption + password. For swap encryption, <filename>/dev/urandom</filename> + or the hardware device <filename>/dev/hw_random</filename> can be + used as the password file; using <filename>/dev/random</filename> + may prevent boot completion if the system does not have enough + entropy to generate a truly random encryption key.</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.</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></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>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>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>_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 be still 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 is also needs to + have <option>noauto</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>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>mke2fs</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + 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>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> + + </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>Example</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.</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</programlisting> + </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..e2bd44e --- /dev/null +++ b/man/custom-entities.ent.in @@ -0,0 +1,10 @@ +<?xml version="1.0" encoding="utf-8" ?> +<!ENTITY MOUNT_PATH @MOUNT_PATH@> +<!ENTITY UMOUNT_PATH @UMOUNT_PATH@> +<!ENTITY systemgeneratordir @SYSTEM_GENERATOR_PATH@> +<!ENTITY usergeneratordir @USER_GENERATOR_PATH@> +<!ENTITY systemenvgeneratordir @SYSTEM_ENV_GENERATOR_PATH@> +<!ENTITY userenvgeneratordir @USER_ENV_GENERATOR_PATH@> +<!ENTITY CERTIFICATE_ROOT @CERTIFICATE_ROOT@> +<!ENTITY MEMORY_ACCOUNTING_DEFAULT @MEMORY_ACCOUNTING_DEFAULT_YES_NO@> +<!ENTITY KILL_USER_PROCESSES @KILL_USER_PROCESSES_YES_NO@> diff --git a/man/custom-html.xsl b/man/custom-html.xsl new file mode 100644 index 0000000..fccaf51 --- /dev/null +++ b/man/custom-html.xsl @@ -0,0 +1,297 @@ +<?xml version='1.0'?> <!--*-nxml-*--> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + +--> + +<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='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> + +<!-- + - 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..d9af519 --- /dev/null +++ b/man/custom-man.xsl @@ -0,0 +1,49 @@ +<?xml version='1.0'?> <!--*-nxml-*--> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..7724bb4 --- /dev/null +++ b/man/daemon.xml @@ -0,0 +1,739 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.</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>/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> + + </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 + <literal>[Install]</literal> 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> 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 + <literal>[Install]</literal> 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/dnssec-trust-anchors.d.xml b/man/dnssec-trust-anchors.d.xml new file mode 100644 index 0000000..d5faee2 --- /dev/null +++ b/man/dnssec-trust-anchors.d.xml @@ -0,0 +1,174 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.</para> + + <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..2257dcb --- /dev/null +++ b/man/environment.d.xml @@ -0,0 +1,100 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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 session 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>The <filename>environment.d</filename> directories contain a list of "global" environment + variable assignments for the user environment. + <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> + parses them and updates the environment exported by the systemd user instance to the services it + starts.</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 noindex='true'>/opt/foo</filename></title> + + <para><filename>/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>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..23ee17d --- /dev/null +++ b/man/file-hierarchy.xml @@ -0,0 +1,799 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.) Since the + directory is accessible to other users of the system, it is + essential that this directory is only written to with the + <citerefentry project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and related calls. This directory is usually flushed at + boot-up. Also, files that are not accessed within a certain + time are usually automatically deleted. If applications find + the environment variable <varname>$TMPDIR</varname> set, they + should prefer using the directory specified in it over + directly referencing <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></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 smaller 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. The same security + restrictions as with <filename>/tmp/</filename> apply, and + hence only + <citerefentry project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry> + or similar calls should be used to make use of this directory. + If applications find the environment variable + <varname>$TMPDIR</varname> set, they should prefer using the + directory specified in it over directly referencing + <filename>/var/tmp/</filename> (see + <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details). </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> + </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 own 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>During runtime, and for local configuration and state, + additional directories are defined:</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. (Note, however, + that user applications installed system-wide should follow the + rules outlined above regarding placing vendor files.)</para> + + <table> + <title>User Package Vendor 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>~/.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 too 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 to the locations + defined by the various relevant specifications.</para> + + <para>During runtime, and for local configuration and state, + additional directories are defined:</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..19857ce --- /dev/null +++ b/man/halt.xml @@ -0,0 +1,161 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.</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 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> + </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/hostname.xml b/man/hostname.xml new file mode 100644 index 0000000..de33a74 --- /dev/null +++ b/man/hostname.xml @@ -0,0 +1,74 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..013f126 --- /dev/null +++ b/man/hostnamectl.xml @@ -0,0 +1,227 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 host name for mounted (but not booted) + system images.</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>--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>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 host names are set, and the pretty host name 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>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/hwdb.xml b/man/hwdb.xml new file mode 100644 index 0000000..7d550c6 --- /dev/null +++ b/man/hwdb.xml @@ -0,0 +1,135 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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 + +# 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 + +evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn123* + KEYBOARD_KEY_a2=wlan + +# /etc/udev/hwdb.d/70-keyboard.hwdb +# disable wlan key on all at keyboards +evdev:atkbd:* + KEYBOARD_KEY_a2=reserved</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:pn123</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</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..8fa557c --- /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.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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>5</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 + <literal>[Remote]</literal> 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..3dda301 --- /dev/null +++ b/man/journal-upload.conf.xml @@ -0,0 +1,93 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>5</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 <literal>[Upload]</literal> 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 <varname>--url=</varname> 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..7ff0a47 --- /dev/null +++ b/man/journalctl.xml @@ -0,0 +1,992 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + + <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.</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 only has an + effect 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>). 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 only + has an effect on the <option>short</option> family of output modes (see above).</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. "-- Logs begin 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><replaceable>ID</replaceable></optional><optional><replaceable>±offset</replaceable></optional></option></term> + <term><option>--boot=<optional><replaceable>ID</replaceable></optional><optional><replaceable>±offset</replaceable></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> + </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.</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.</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>-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><refentrytitle>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 insenstive.</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>--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, journalctl 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>--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, 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>--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>5</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..2791678 --- /dev/null +++ b/man/journald.conf.xml @@ -0,0 +1,425 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + <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> + </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>5</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 + <literal>[Journal]</literal> 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> is similar to + <literal>persistent</literal> but the directory + <filename>/var/log/journal</filename> is not created if + needed, so that its existence controls where log data goes. + <literal>none</literal> turns off all storage, all log data + received will be dropped. Forwarding to other targets, such as + the console, the kernel log buffer, or a syslog socket will + still work however. Defaults to + <literal>auto</literal>.</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 will each get their own journal files, and system users will log to + the system journal. 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>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. When forwarding to the + console, the TTY to log to can be changed with <varname>TTYPath=</varname>, + described below.</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 on disk, 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 written to disk 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 (the + default), journal reads <filename>/dev/kmsg</filename> + messages generated by the kernel.</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 NUL 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..43dfc10 --- /dev/null +++ b/man/kernel-command-line.xml @@ -0,0 +1,454 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.</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.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 to specifies 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><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 as usual, 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. 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_priority=</varname></term> + <term><varname>rd.udev.log_priority=</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>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-writable 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>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> + + <listitem> + <para>Enables resume from hibernation using the specified + device. 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.</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> + </para> + </refsect1> + +</refentry> diff --git a/man/kernel-install.xml b/man/kernel-install.xml new file mode 100644 index 0000000..50e1320 --- /dev/null +++ b/man/kernel-install.xml @@ -0,0 +1,202 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="kernel-install"> + + <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="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 <filename>/boot</filename>. + </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> creates the directory + <filename>/boot/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> + and 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>Two default plugins execute the following operations in this case:</para> + + <itemizedlist> + + <listitem><para><filename>50-depmod.install</filename> runs + <citerefentry><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></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>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 the file specifies the machine identification <replaceable>MACHINE-ID</replaceable>.</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><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..eb332b5 --- /dev/null +++ b/man/less-variables.xml @@ -0,0 +1,46 @@ +<?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+ +--> + +<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>If the value of <varname>$SYSTEMD_LESS</varname> does not include <literal>K</literal>, + and the pager that is invoked is <command>less</command>, + <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> will be ignored by the + executable. This allows <command>less</command> to handle + <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> itself.</para></listitem> + </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> + + </variablelist> +</refsect1> diff --git a/man/libsystemd-pkgconfig.xml b/man/libsystemd-pkgconfig.xml new file mode 100644 index 0000000..a177fbe --- /dev/null +++ b/man/libsystemd-pkgconfig.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+ +--> + +<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..382c1aa --- /dev/null +++ b/man/libudev.xml @@ -0,0 +1,99 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..f9d98dd --- /dev/null +++ b/man/loader.conf.xml @@ -0,0 +1,185 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </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..2f463de --- /dev/null +++ b/man/locale.conf.xml @@ -0,0 +1,130 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..50c7e13 --- /dev/null +++ b/man/localectl.xml @@ -0,0 +1,212 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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>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>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..f51c67f --- /dev/null +++ b/man/localtime.xml @@ -0,0 +1,72 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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..67eeffd --- /dev/null +++ b/man/loginctl.xml @@ -0,0 +1,432 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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>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>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..ac8032a --- /dev/null +++ b/man/logind.conf.xml @@ -0,0 +1,349 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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>5</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 + <literal>[Login]</literal> 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 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> + + <listitem><para>Controls how logind shall handle the + system power and sleep keys and the lid switch to trigger + actions such as system power-off 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>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>). + 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> + + <listitem><para>Controls whether actions that <command>systemd-logind</command> + takes when the power and sleep keys and the lid switch are triggered are subject + to high-level inhibitor locks ("shutdown", "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>), + 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", "sleep", and "idle" inhibitor locks are ignored. + <varname>PowerKeyIgnoreInhibited=</varname>, + <varname>SuspendKeyIgnoreInhibited=</varname>, and + <varname>HibernateKeyIgnoreInhibited=</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 the timeout 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>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..7ed2dda --- /dev/null +++ b/man/machine-id.xml @@ -0,0 +1,172 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 is 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 an empty file in the generic file + system image. 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> (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>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..5a268c9 --- /dev/null +++ b/man/machine-info.xml @@ -0,0 +1,162 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 host name 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..95823eb --- /dev/null +++ b/man/machinectl.xml @@ -0,0 +1,1010 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 host names. 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>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.</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. + If multiple addresses are to be written for a given machine, every + address except the first one is on a new line and is followed by + <literal>,</literal> if another address will be output afterwards. </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>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 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 host name, 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>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 host names + 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 service</title> + + <programlisting># machinectl pull-raw --verify=no https://dl.fedoraproject.org/pub/fedora/linux/releases/27/CloudImages/x86_64/images/Fedora-Cloud-Base-27-1.6.x86_64.raw.xz +# systemd-nspawn -M Fedora-Cloud-Base-27-1.6.x86_64 +# passwd +# exit +# machinectl start Fedora-Cloud-Base-27-1.6.x86_64 +# machinectl login Fedora-Cloud-Base-27-1.6.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/meson.build b/man/meson.build new file mode 100644 index 0000000..05197d6 --- /dev/null +++ b/man/meson.build @@ -0,0 +1,209 @@ +# SPDX-License-Identifier: LGPL-2.1+ + +# 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 = [] +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, + 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 + 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 + + source_xml_files += files(tuple[0] + '.xml') + 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 : source_xml_files, + output : 'systemd.directives.xml', + command : [make_directive_index_py, '@OUTPUT@'] + source_xml_files) + +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 git.found() + custom_target( + 'update-man-rules', + output : 'update-man-rules', + # slightly strange syntax because of + # https://github.com/mesonbuild/meson/issues/1643 + # and https://github.com/mesonbuild/meson/issues/1512 + command : ['sh', '-c', + 'cd @0@ && '.format(meson.build_root()) + + 'python3 @0@/tools/make-man-rules.py `git ls-files ":/man/*.xml"` >t && '.format(meson.source_root()) + + 'mv t @0@/rules/meson.build'.format(meson.current_source_dir())], + depend_files : custom_entities_ent) +endif diff --git a/man/modules-load.d.xml b/man/modules-load.d.xml new file mode 100644 index 0000000..57c4c68 --- /dev/null +++ b/man/modules-load.d.xml @@ -0,0 +1,77 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..7877755 --- /dev/null +++ b/man/networkctl.xml @@ -0,0 +1,278 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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> + + <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>Commands</title> + + <para>The following commands are understood:</para> + + <variablelist> + <varlistentry> + <term> + <command>list</command> + <optional><replaceable>LINK…</replaceable></optional> + </term> + + <listitem> + <para>Show a list of existing links and their status. 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>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>carrier</term> + <listitem> + <para>the link has a carrier</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>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>LINK…</replaceable></optional> + </term> + + <listitem> + <para>Show information about the specified links: type, + state, kernel module driver, hardware and IP address, + configured DNS servers, etc.</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>LINK…</replaceable></optional> + </term> + + <listitem> + <para>Show discovered LLDP (Link Layer Discovery Protocol) neighbors. If one or more link names 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><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> + + </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..c624d4d --- /dev/null +++ b/man/networkd.conf.xml @@ -0,0 +1,147 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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>[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..e447420 --- /dev/null +++ b/man/nss-myhostname.xml @@ -0,0 +1,125 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>Provide 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> last in the <filename>nsswitch.conf</filename>' + <literal>hosts:</literal> line to make sure that this mapping is only used as fallback, and that any DNS or + <filename>/etc/hosts</filename> based mapping takes precedence.</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 mymachines systemd +group: compat mymachines systemd +shadow: compat + +hosts: files mymachines resolve [!UNAVAIL=return] 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..5742d89 --- /dev/null +++ b/man/nss-mymachines.xml @@ -0,0 +1,163 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>Provide 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>The module also provides name resolution for user and group identifiers mapped to containers. All names from + the range allocated to a given container <replaceable>container</replaceable> are exposed on the host as + <literal>vu-<replaceable>container</replaceable>-<replaceable>uid</replaceable></literal> and + <literal>vg-<replaceable>container</replaceable>-<replaceable>gid</replaceable></literal> (see example below). This + functionality only applies to containers using user namespacing (see the description of + <option>--private-users</option> in + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para> + + <para>To activate the NSS module, add <literal>mymachines</literal> to the lines starting with + <literal>hosts:</literal>, <literal>passwd:</literal> and <literal>group:</literal> in + <filename>/etc/nsswitch.conf</filename>.</para> + + <para>It is recommended to place <literal>mymachines</literal> after the <literal>files</literal> or + <literal>compat</literal> entry of the <filename>/etc/nsswitch.conf</filename> lines to make sure that its mappings + are preferred over other resolvers such as DNS, but so that <filename>/etc/hosts</filename>, + <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-mymachines</command> correctly:</para> + + <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf --> + <programlisting>passwd: compat <command>mymachines</command> systemd +group: compat <command>mymachines</command> systemd +shadow: compat + +hosts: files <command>mymachines</command> resolve [!UNAVAIL=return] dns myhostname +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis</programlisting> + + </refsect1> + + <refsect1> + <title>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 + +$ getent passwd vu-rawhide-0 vu-rawhide-81 +vu-rawhide-0:*:20119552:65534:vu-rawhide-0:/:/sbin/nologin +vu-rawhide-81:*:20119633:65534:vu-rawhide-81:/:/sbin/nologin + +$ 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 + +$ 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..960d580 --- /dev/null +++ b/man/nss-resolve.xml @@ -0,0 +1,95 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>Provide 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 host names 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</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 (but + after the <literal>files</literal> or <literal>mymachines</literal> entries), right before the + <literal>dns</literal> entry if it exists, followed by <literal>[!UNAVAIL=return]</literal>, to ensure DNS queries + are always routed via + <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry> if it is + running, but are routed to <command>nss-dns</command> if this service 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 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 mymachines systemd +group: compat mymachines systemd +shadow: compat + +hosts: files mymachines <command>resolve [!UNAVAIL=return]</command> dns myhostname +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..d3d6843 --- /dev/null +++ b/man/nss-systemd.xml @@ -0,0 +1,88 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>Provide UNIX user and group name resolution for dynamic users and groups.</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 dynamic users and + groups allocated through the <varname>DynamicUser=</varname> option in systemd unit files. See + <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details on + this option.</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>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>Example</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 mymachines <command>systemd</command> +group: compat mymachines <command>systemd</command> +shadow: compat + +hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname +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.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 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/os-release.xml b/man/os-release.xml new file mode 100644 index 0000000..6de0cd7 --- /dev/null +++ b/man/os-release.xml @@ -0,0 +1,374 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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, or + <literal>ANSI_COLOR="1;34"</literal> for light + 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> + </refsect1> + + <refsect1> + <title>Example</title> + + <programlisting>NAME=Fedora +VERSION="17 (Beefy Miracle)" +ID=fedora +VERSION_ID=17 +PRETTY_NAME="Fedora 17 (Beefy Miracle)" +ANSI_COLOR="0;34" +CPE_NAME="cpe:/o:fedoraproject:fedora:17" +HOME_URL="https://fedoraproject.org/" +BUG_REPORT_URL="https://bugzilla.redhat.com/"</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..e5e14c1 --- /dev/null +++ b/man/pam_systemd.xml @@ -0,0 +1,312 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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> + </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 for the current session.</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> + + </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>session=</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 NUL-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><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> + </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); + </programlisting> + </para> + + </refsect1> + + <refsect1> + <title>Example</title> + + <programlisting>#%PAM-1.0 +auth required pam_unix.so +auth required pam_nologin.so +account required pam_unix.so +password required pam_unix.so +session required pam_unix.so +session required pam_loginuid.so +session required pam_systemd.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 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/portablectl.xml b/man/portablectl.xml new file mode 100644 index 0000000..3a5517a --- /dev/null +++ b/man/portablectl.xml @@ -0,0 +1,401 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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>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> + + <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>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 and 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> + </listitem> + </varlistentry> + + <varlistentry> + <term><command>detach</command> <replaceable>IMAGE</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 convencience feature to allow all arguments passed as <command>attach</command> also to + <command>detach</command>.</para></listitem> + </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 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>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 this profiles, and their effects please have a look at 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/resolvectl.xml b/man/resolvectl.xml new file mode 100644 index 0000000..defd592 --- /dev/null +++ b/man/resolvectl.xml @@ -0,0 +1,447 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> host name or all data from <filename>/etc/hosts</filename>.</para> + </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>Commands</title> + <variablelist> + + <varlistentry> + <term><option>query <replaceable>HOSTNAME|ADDRESS</replaceable>…</option></term> + + <listitem><para>Resolve domain names, IPv4 and IPv6 addresses.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>service [[<replaceable>NAME</replaceable>] <replaceable>TYPE</replaceable>] <replaceable>DOMAIN</replaceable></option></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><option>openpgp <replaceable>EMAIL@DOMAIN</replaceable>…</option></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><option>tlsa [<replaceable>FAMILY</replaceable>] <replaceable>DOMAIN</replaceable>[:<replaceable>PORT</replaceable>]…</option></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><option>status [<replaceable>LINK</replaceable>…]</option></term> + + <listitem><para>Shows the global and per-link DNS settings in currently in effect. If no command is specified, + this is the implied default.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>statistics</option></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><option>reset-statistics</option></term> + + <listitem><para>Resets the statistics counters shown in <option>statistics</option> to zero. + This operation requires root privileges.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>flush-caches</option></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><option>reset-server-features</option></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><option>dns [<replaceable>LINK</replaceable> [<replaceable>SERVER</replaceable>…]]</option></term> + <term><option>domain [<replaceable>LINK</replaceable> [<replaceable>DOMAIN</replaceable>…]]</option></term> + <term><option>default-route [<replaceable>LINK</replaceable> [<replaceable>BOOL</replaceable>…]]</option></term> + <term><option>llmnr [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</option></term> + <term><option>mdns [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</option></term> + <term><option>dnssec [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</option></term> + <term><option>dnsovertls [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</option></term> + <term><option>nta [<replaceable>LINK</replaceable> [<replaceable>DOMAIN</replaceable>…]]</option></term> + + <listitem> + <para>Get/set per-interface DNS configuration. These commands may be used to configure various DNS settings + for network interfaces that aren't managed by + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. (These + commands will fail when used on interfaces that are managed by <command>systemd-networkd</command>, please + configure their DNS settings directly inside the <filename>.network</filename> files instead.) These commands + may be used to inform <command>systemd-resolved</command> about per-interface DNS configuration determined + through external means. The <option>dns</option> command expects IPv4 or IPv6 address specifications of DNS + servers to use. The <option>domain</option> command expects valid DNS domains, possibly prefixed with + <literal>~</literal>, and configures a per-interface search or route-only domain. The + <option>default-route</option> command expects a boolean paremeter, and configures whether the link may be + used as default route for DNS lookups, i.e. if it is suitable for lookups on domains no other link explicitly + is configured for. The <option>llmnr</option>, <option>mdns</option>, <option>dnssec</option> and + <option>dnsovertls</option> commands may be used to configure the per-interface LLMNR, MulticastDNS, DNSSEC + and DNSOverTLS settings. Finally, <option>nta</option> command may be used to configure additional + per-interface DNSSEC NTA domains.</para> + + <para>Options <option>dns</option>, <option>domain</option> and <option>nta</option> 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 options in + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><option>revert <replaceable>LINK</replaceable></option></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 <option>dns</option>, + <option>domain</option>, <option>default-route</option>, <option>llmnr</option>, <option>mdns</option>, + <option>dnssec</option>, <option>dnsovertls</option>, <option>nta</option>. Note that when a network interface + disappears all configuration is lost automatically, an explicit reverting is not necessary in that + case.</para></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Compatibility with <citerefentry><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><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. Note that 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><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><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details on this 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..d37bf0d --- /dev/null +++ b/man/resolved.conf.xml @@ -0,0 +1,272 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 <literal>[Resolve]</literal> 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. 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. 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. These domains are used as search suffixes when resolving + single-label host names (domain names which contain no dot), in order to qualify them into fully-qualified + domain names (FQDNs). Search domains are strictly processed in the order they are specified, 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> are used instead, if that file exists and any domains + are configured in it. This setting defaults to the empty list.</para> + + <para>Specified domain names may optionally be prefixed with <literal>~</literal>. In this case they do not + define a search path, but preferably direct DNS queries for the indicated domains to the DNS servers configured + with the system <varname>DNS=</varname> setting (see above), in case additional, suitable per-link DNS servers + are known. If no per-link DNS servers are known using the <literal>~</literal> syntax has no effect. Use the + construct <literal>~.</literal> (which is composed of <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 + system DNS server defined with <varname>DNS=</varname> 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 false or + <literal>opportunistic</literal>. 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 as the resolver is not capable of authenticating + the server, it is vulnerable for "man-in-the-middle" attacks.</para> + + <para>In addition to this global DNSOverTLS setting + <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + also maintains per-link DNSOverTLS settings. For system DNS + servers (see above), only the global DNSOverTLS 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 argument. If <literal>yes</literal> (the default), resolving a domain name + which already got queried earlier will return the previous result as long as it is still valid, and thus does + not result in a new network request. Be aware that turning off caching comes at a performance penalty, which + is particularly high when DNSSEC is used.</para> + + <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>ReadEtcHosts=</varname></term> + <listitem><para>Takes a boolean argument. If <literal>yes</literal> (the default), the DNS stub resolver 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> + + </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..0c990a0 --- /dev/null +++ b/man/rules/meson.build @@ -0,0 +1,919 @@ +# Do not edit. Generated by make-man-rules.py. +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'], ''], + ['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'], ''], + ['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'], + ['os-release', '5', [], ''], + ['pam_systemd', '8', [], 'HAVE_PAM'], + ['portablectl', '1', [], 'ENABLE_PORTABLED'], + ['resolvectl', '1', ['resolvconf'], 'ENABLE_RESOLVE'], + ['resolved.conf', '5', ['resolved.conf.d'], 'ENABLE_RESOLVE'], + ['runlevel', '8', [], 'ENABLE_UTMP'], + ['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-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_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_attach_event', '3', ['sd_bus_detach_event', 'sd_bus_get_event'], ''], + ['sd_bus_close', '3', ['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_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_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_fd', '3', ['sd_bus_get_events', 'sd_bus_get_timeout'], ''], + ['sd_bus_get_n_queued_read', '3', ['sd_bus_get_n_queued_write'], ''], + ['sd_bus_is_open', '3', ['sd_bus_is_ready'], ''], + ['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_copy', '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_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_read', '3', ['sd_bus_message_readv'], ''], + ['sd_bus_message_read_array', '3', [], ''], + ['sd_bus_message_read_basic', '3', [], ''], + ['sd_bus_message_rewind', '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_auto_start', + 'sd_bus_message_get_expect_reply', + 'sd_bus_message_set_auto_start'], + ''], + ['sd_bus_message_skip', '3', [], ''], + ['sd_bus_message_verify_type', '3', [], ''], + ['sd_bus_negotiate_fds', + '3', + ['sd_bus_negotiate_creds', 'sd_bus_negotiate_timestamp'], + ''], + ['sd_bus_new', + '3', + ['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_reply_method_error', + '3', + ['sd_bus_reply_method_errno', + 'sd_bus_reply_method_errnof', + 'sd_bus_reply_method_errorf'], + ''], + ['sd_bus_request_name', + '3', + ['sd_bus_release_name', + 'sd_bus_release_name_async', + 'sd_bus_request_name_async'], + ''], + ['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_set_allow_interactive_authorization', + 'sd_bus_set_anonymous', + 'sd_bus_set_trusted'], + ''], + ['sd_bus_set_sender', '3', ['sd_bus_get_sender'], ''], + ['sd_bus_set_watch_bind', '3', ['sd_bus_get_watch_bind'], ''], + ['sd_bus_slot_ref', + '3', + ['sd_bus_slot_get_bus', '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_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_child_handler_t', 'sd_event_source_get_child_pid'], + ''], + ['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_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_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_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_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_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_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_CURRENT_USER', + '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_print', + '3', + ['SD_JOURNAL_SUPPRESS_LOCATION', + 'sd_journal_perror', + 'sd_journal_printv', + 'sd_journal_send', + 'sd_journal_sendv'], + ''], + ['sd_journal_query_unique', + '3', + ['SD_JOURNAL_FOREACH_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_notifyf', 'sd_pid_notify', 'sd_pid_notify_with_fds', 'sd_pid_notifyf'], + ''], + ['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_multi_session', + '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', [], ''], + ['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', [], 'ENABLE_EFI'], + ['systemd-boot-check-no-failures.service', '8', [], ''], + ['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-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', [], ''], + ['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-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'], + ''], + ['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.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-makeswap@.service'], + ''], + ['systemd-modules-load.service', '8', ['systemd-modules-load'], 'HAVE_KMOD'], + ['systemd-mount', '1', ['systemd-umount'], ''], + ['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-path', '1', [], ''], + ['systemd-portabled.service', '8', ['systemd-portabled'], 'ENABLE_PORTABLED'], + ['systemd-quotacheck.service', + '8', + ['systemd-quotacheck'], + 'ENABLE_QUOTACHECK'], + ['systemd-random-seed.service', + '8', + ['systemd-random-seed'], + 'ENABLE_RANDOMSEED'], + ['systemd-rc-local-generator', '8', [], ''], + ['systemd-remount-fs.service', '8', ['systemd-remount-fs'], ''], + ['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-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-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', '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.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', [], ''], + ['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_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_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', ['user-runtime-dir@.service'], ''], + ['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..8b5025d --- /dev/null +++ b/man/runlevel.xml @@ -0,0 +1,167 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="runlevel" + xmlns:xi="http://www.w3.org/2001/XInclude" + conditional="ENABLE_UTMP"> + + <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-errors.xml b/man/sd-bus-errors.xml new file mode 100644 index 0000000..a94022c --- /dev/null +++ b/man/sd-bus-errors.xml @@ -0,0 +1,278 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..4620590 --- /dev/null +++ b/man/sd-bus.xml @@ -0,0 +1,113 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_creds_get_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_default</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_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_get_n_queued_read</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_copy</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_cookie</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_get_monotonic_usec</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_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_rewind</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_message_set_destination</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_reply_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_request_name</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_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>, +<citerefentry><refentrytitle>sd_bus_set_watch_bind</refentrytitle><manvolnum>3</manvolnum></citerefentry> +<citerefentry><refentrytitle>sd_bus_set_close_on_exit</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_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..a404213 --- /dev/null +++ b/man/sd-daemon.xml @@ -0,0 +1,120 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 as implemented by systemd. If a systemd + service definition file is configured with + <varname>StandardError=journal</varname>, + <varname>StandardError=syslog</varname> or + <varname>StandardError=kmsg</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..2e6ab69 --- /dev/null +++ b/man/sd-event.xml @@ -0,0 +1,165 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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-id128.xml b/man/sd-id128.xml new file mode 100644 index 0000000..4425c45 --- /dev/null +++ b/man/sd-id128.xml @@ -0,0 +1,165 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_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><function>SD_ID128_NULL</function> may be used to refer to the 128bit ID consisting of only NUL + 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><function>SD_ID128_FORMAT_STR()</function> 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>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 NUL 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..3fa6c75 --- /dev/null +++ b/man/sd-journal.xml @@ -0,0 +1,121 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..3743957 --- /dev/null +++ b/man/sd-login.xml @@ -0,0 +1,251 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 Plugable 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> + for an introduction to multi-seat support on Linux and the background for this set of APIs. + </para> + </refsect1> + +</refentry> diff --git a/man/sd_booted.xml b/man/sd_booted.xml new file mode 100644 index 0000000..ace5417 --- /dev/null +++ b/man/sd_booted.xml @@ -0,0 +1,71 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..c4f24ae --- /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.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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> + <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_attach_event.xml b/man/sd_bus_attach_event.xml new file mode 100644 index 0000000..a2f7297 --- /dev/null +++ b/man/sd_bus_attach_event.xml @@ -0,0 +1,122 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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_close.xml b/man/sd_bus_close.xml new file mode 100644 index 0000000..369afd8 --- /dev/null +++ b/man/sd_bus_close.xml @@ -0,0 +1,101 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + + <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> + </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 receieved 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> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>sd_bus_flush()</function> returns 0 or a positive integer. On failure, it returns a + negative errno-style error code.</para> + </refsect1> + + <refsect1> + <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> + </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..c068fbf --- /dev/null +++ b/man/sd_bus_creds_get_pid.xml @@ -0,0 +1,537 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.</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 NUL-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 NUL-terminated, and the + array is NULL-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> + </refsect1> + + <refsect1> + <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> + </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..eda5d17 --- /dev/null +++ b/man/sd_bus_creds_new_from_pid.xml @@ -0,0 +1,320 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..dfb32b9 --- /dev/null +++ b/man/sd_bus_default.xml @@ -0,0 +1,324 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + prefereable 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>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> + </refsect1> + + <refsect1> + <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>-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, any further connection-related errors may be + by returned. See <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</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_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_unref</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_error.xml b/man/sd_bus_error.xml new file mode 100644 index 0000000..36cdf4c --- /dev/null +++ b/man/sd_bus_error.xml @@ -0,0 +1,371 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + + <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> + </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 NULL. An unset <structname>sd_bus_error</structname> structure + should have both fields initialized to NULL. Set an error + structure to <constant>SD_BUS_ERROR_NULL</constant> in order to + reset both fields to NULL. 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 NULL, 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 NULL, 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_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 NULL), + 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 NULL. 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> returns a + non-zero value when <parameter>e</parameter> is + non-<constant>NULL</constant> and the + <structfield>name</structfield> field is equal to + <parameter>name</parameter>, 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> + </refsect1> + + <refsect1> + <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> + </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..dbe05a1 --- /dev/null +++ b/man/sd_bus_error_add_map.xml @@ -0,0 +1,142 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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_fd.xml b/man/sd_bus_get_fd.xml new file mode 100644 index 0000000..2a81bdd --- /dev/null +++ b/man/sd_bus_get_fd.xml @@ -0,0 +1,160 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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_get_events</refname> + <refname>sd_bus_get_timeout</refname> + + <refpurpose>Get the file descriptor, I/O events and time-out 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_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 + <citerefentry><refentrytitle>sd_bus_set_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> function, then + the <parameter>input_fd</parameter> file descriptor used in that call is returned.</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 time-out in µs to pass to to + <function>poll()</function> or a similar call when waiting for events on the specified bus connection. The returned + time-out 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 time-out. Note that the returned time-out should be considered only a maximum sleeping time. It + is permissible (and even expected) that shorter time-outs 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 time-outs 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 time-out 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 function 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><function>sd_bus_get_fd()</function> returns the file descriptor used for communication, or a negative + <varname>errno</varname>-style error code on error.</para> + + <para><function>sd_bus_get_events()</function> returns the I/O event mask to use for I/O event watching, or a + negative <varname>errno</varname>-style error code on error.</para> + + <para><function>sd_bus_get_timeout()</function> returns zero or positive on success, or a negative + <varname>errno</varname>-style error code on error.</para> + </refsect1> + + <refsect1> + <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> + </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_set_fd</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..76ad659 --- /dev/null +++ b/man/sd_bus_get_n_queued_read.xml @@ -0,0 +1,103 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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_is_open.xml b/man/sd_bus_is_open.xml new file mode 100644 index 0000000..0388db8 --- /dev/null +++ b/man/sd_bus_is_open.xml @@ -0,0 +1,106 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 a 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> + </refsect1> + + <refsect1> + <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> + </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_message_append.xml b/man/sd_bus_message_append.xml new file mode 100644 index 0000000..1fdda51 --- /dev/null +++ b/man/sd_bus_message_append.xml @@ -0,0 +1,253 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>The <function>sd_bus_message_appendv()</function> is equivalent to the + <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 "s" and "g" (unicode string or signature), the pointer may be + <constant>NULL</constant>, which is equivalent to an empty string. 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 0 or a positive + integer. On failure, these functions return a negative + errno-style error code.</para> + </refsect1> + + <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" /> + + <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> + </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..746f9e3 --- /dev/null +++ b/man/sd_bus_message_append_array.xml @@ -0,0 +1,181 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>char 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>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> + </refsect1> + + <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" /> + + <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..abd3bae --- /dev/null +++ b/man/sd_bus_message_append_basic.xml @@ -0,0 +1,264 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1 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> + </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..4224af0 --- /dev/null +++ b/man/sd_bus_message_append_string_memfd.xml @@ -0,0 +1,122 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 returns a negative errno-style error code.</para> + </refsect1> + + <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" /> + + <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..5f1a4f5 --- /dev/null +++ b/man/sd_bus_message_append_strv.xml @@ -0,0 +1,84 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" /> + + <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_copy.xml b/man/sd_bus_message_copy.xml new file mode 100644 index 0000000..ac2a4f3 --- /dev/null +++ b/man/sd_bus_message_copy.xml @@ -0,0 +1,115 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1 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> + </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_get_cookie.xml b/man/sd_bus_message_get_cookie.xml new file mode 100644 index 0000000..cc9a445 --- /dev/null +++ b/man/sd_bus_message_get_cookie.xml @@ -0,0 +1,114 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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, these calls 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> + </refsect1> + + <refsect1> + <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> + </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..06ea227 --- /dev/null +++ b/man/sd_bus_message_get_monotonic_usec.xml @@ -0,0 +1,147 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..bee6778 --- /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.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </refsect1> + + <refsect1> + <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> + </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..6f6b7d0 --- /dev/null +++ b/man/sd_bus_message_get_type.xml @@ -0,0 +1,129 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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_is_signal</refname> + <refname>sd_bus_message_is_method_call</refname> + <refname>sd_bus_message_is_method_error</refname> + + <refpurpose>Query bus message addressing 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>message</parameter></paramdef> + <paramdef>uint8_t *<parameter>type</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_bus_message_is_signal</function></funcdef> + <paramdef>sd_bus_message *<parameter>message</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>message</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>message</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_set_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + or is set automatically when the message is created using + <citerefentry><refentrytitle>sd_bus_set_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_set_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry> + and similar functions. + </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_set_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_set_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_set_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, those functions return 0 or a positive + integer. On failure, it returns a negative errno-style error code.</para> + </refsect1> + + <refsect1> + <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> + </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_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_set_destination</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..78bca8a --- /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.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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 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> + </refsect1> + + <refsect1> + <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> + </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..c643177 --- /dev/null +++ b/man/sd_bus_message_new_method_call.xml @@ -0,0 +1,166 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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 sd_bus_message_new_method_call</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 sd_bus_message_new_method_return</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>The <function>sd_bus_message_new_method_call()</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>This function returns 0 if the message object was successfully created, and a negative + errno-style error code otherwise.</para> + </refsect1> + + <refsect1 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> + </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_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..045c74f --- /dev/null +++ b/man/sd_bus_message_new_method_error.xml @@ -0,0 +1,190 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 a 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><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><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 initalized + 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> + </refsect1> + + <refsect1 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>error</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> + </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..c9ed0bc --- /dev/null +++ b/man/sd_bus_message_new_signal.xml @@ -0,0 +1,120 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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_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> + </refsect1> + + <refsect1 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>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> + </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> + </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..2815c01 --- /dev/null +++ b/man/sd_bus_message_read.xml @@ -0,0 +1,232 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + + <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>char 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>char char *<parameter>types</parameter></paramdef> + <paramdef>va_list <parameter>ap</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 <code>int8_t</code> for a <literal>y</literal> in + the type string, a pointer to <code>int32_t</code> for an <literal>i</literal>, a pointer to + <code>const char*</code> for an <literal>s</literal>, ...) which are set based on the values in + the message. As an exception, in case or 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., <code>const char *</code> 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.</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>int, 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> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para> + On success, <function>sd_bus_message_read()</function> and + <function>sd_bus_message_readv()</function> return 0 or a positive integer. On + failure, they return a negative errno-style error code. + </para> + </refsect1> + + <xi:include href="sd_bus_message_read_basic.xml" xpointer="errors" /> + + <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 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> + </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> + </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..3148127 --- /dev/null +++ b/man/sd_bus_message_read_array.xml @@ -0,0 +1,108 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> gives access to an element array in + 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 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 <parameter>size</parameter> is 0, a + valid non-null pointer will be returned, 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> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para> + On success, <function>sd_bus_message_read_array()</function> returns 0 or + a positive integer. On failure, it returns a negative errno-style error + code. + </para> + </refsect1> + + <refsect1 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 is invalid 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> + </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_read_basic.xml b/man/sd_bus_message_read_basic.xml new file mode 100644 index 0000000..774d3fc --- /dev/null +++ b/man/sd_bus_message_read_basic.xml @@ -0,0 +1,235 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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 <code>uint8_t *</code>. If <parameter>type</parameter> is + <constant>'s'</constant>, the object passed in <parameter>p</parameter> should + have type <code>const char **</code>. Note that, if the basic type is a pointer + (e.g., <code>const char *</code> 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. 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>unsigned integer</entry> + <entry>uint8_t *</entry> + </row> + + <row> + <entry><literal>b</literal></entry> + <entry><constant>SD_BUS_TYPE_BOOLEAN</constant></entry> + <entry>boolean</entry> + <entry>int *</entry> + </row> + + <row> + <entry><literal>n</literal></entry> + <entry><constant>SD_BUS_TYPE_INT16</constant></entry> + <entry>signed integer</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>uint16_t *</entry> + </row> + + <row> + <entry><literal>i</literal></entry> + <entry><constant>SD_BUS_TYPE_INT32</constant></entry> + <entry>signed integer</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>uint32_t *</entry> + </row> + + <row> + <entry><literal>x</literal></entry> + <entry><constant>SD_BUS_TYPE_INT64</constant></entry> + <entry>signed integer</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>uint64_t *</entry> + </row> + + <row> + <entry><literal>d</literal></entry> + <entry><constant>SD_BUS_TYPE_DOUBLE</constant></entry> + <entry>floating-point</entry> + <entry>double *</entry> + </row> + + <row> + <entry><literal>s</literal></entry> + <entry><constant>SD_BUS_TYPE_STRING</constant></entry> + <entry>Unicode string</entry> + <entry>const char **</entry> + </row> + + <row> + <entry><literal>o</literal></entry> + <entry><constant>SD_BUS_TYPE_OBJECT_PATH</constant></entry> + <entry>object path</entry> + <entry>const char **</entry> + </row> + + <row> + <entry><literal>g</literal></entry> + <entry><constant>SD_BUS_TYPE_SIGNATURE</constant></entry> + <entry>signature</entry> + <entry>const char **</entry> + </row> + + <row> + <entry><literal>h</literal></entry> + <entry><constant>SD_BUS_TYPE_UNIX_FD</constant></entry> + <entry>UNIX file descriptor</entry> + <entry>int *</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 0 or + a positive integer. On failure, it returns a negative errno-style error + code. + </para> + </refsect1> + + <refsect1 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> + </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_rewind.xml b/man/sd_bus_message_rewind.xml new file mode 100644 index 0000000..c420c2f --- /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.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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 begining 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 begining 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> + </refsect1> + + <xi:include href="libsystemd-pkgconfig.xml" /> + + <refsect1> + <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> + </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_set_destination.xml b/man/sd_bus_message_set_destination.xml new file mode 100644 index 0000000..e8a1206 --- /dev/null +++ b/man/sd_bus_message_set_destination.xml @@ -0,0 +1,156 @@ +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> or + <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> + </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..2dfabca --- /dev/null +++ b/man/sd_bus_message_set_expect_reply.xml @@ -0,0 +1,127 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + + <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> + </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> + </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> + </refsect1> + + <refsect1> + <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> + </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..384a791 --- /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.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </refsect1> + + <refsect1> + <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> + </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..fcb9f19 --- /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.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </refsect1> + + <refsect1 id='errors'> + <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 contraints listed above.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>Message <parameter>m</parameter> is not sealed. + </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_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..c8d520e --- /dev/null +++ b/man/sd_bus_negotiate_fds.xml @@ -0,0 +1,147 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + + <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> + </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>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 0 or a + positive integer. On failure, they return a negative errno-style + error code.</para> + </refsect1> + + <refsect1> + <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> + </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_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_bus_message_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..cc08e6b --- /dev/null +++ b/man/sd_bus_new.xml @@ -0,0 +1,204 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 a better idea to invoke + <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 calls not + only allocate a bus object but also start the connection to a + well-known bus in a single function invocation.</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> + </refsect1> + + <refsect1> + <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> + </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..03130a6 --- /dev/null +++ b/man/sd_bus_path_encode.xml @@ -0,0 +1,156 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 <literal>NULL</literal> 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, NULL 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..66f22c2 --- /dev/null +++ b/man/sd_bus_process.xml @@ -0,0 +1,133 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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 NULL, progress was made, but no message was + processed, <parameter>*ret</parameter> is set to <constant>NULL</constant>.</para> + + <para>If a 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> + </refsect1> + + <refsect1> + <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> + </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_reply_method_error.xml b/man/sd_bus_reply_method_error.xml new file mode 100644 index 0000000..bbb916d --- /dev/null +++ b/man/sd_bus_reply_method_error.xml @@ -0,0 +1,161 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_errno</refname> + <refname>sd_bus_reply_method_errnof</refname> + + <refpurpose>Reply with an error to a 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_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> + </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_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + If no reply is expected to <parameter>call</parameter>, this function returns + success without sending 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>These functions return 0 if the error reply was successfully sent or if + none was expected, and a negative errno-style error code otherwise.</para> + </refsect1> + + <refsect1 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> 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>error</parameter> 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 message returned by + <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>1</manvolnum></citerefentry> + may be returned.</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_message_new_method_error</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..cf0b552 --- /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.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + + <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 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 is already acquired by another peer, and that other peer has permitted + takeover by setting <constant>SD_BUS_NAME_ALLOW_REPLACEMENT</constant> while acquiring it.</para></listitem> + </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> + </refsect1> + + <refsect1> + <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> + </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_set_close_on_exit.xml b/man/sd_bus_set_close_on_exit.xml new file mode 100644 index 0000000..dc4f6a3 --- /dev/null +++ b/man/sd_bus_set_close_on_exit.xml @@ -0,0 +1,105 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 0 or a positive 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 turned off or a + positive integer if it is on. On failure, it returns a negative errno-style error code.</para> + </refsect1> + + <refsect1> + <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> + </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..32fc630 --- /dev/null +++ b/man/sd_bus_set_connected_signal.xml @@ -0,0 +1,112 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 emmission 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> + </refsect1> + + <refsect1> + <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> + </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..af02c20 --- /dev/null +++ b/man/sd_bus_set_description.xml @@ -0,0 +1,188 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_set_trusted</refname> + <refname>sd_bus_set_allow_interactive_authorization</refname> + <refname>sd_bus_get_allow_interactive_authorization</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_set_trusted</function></funcdef> + <paramdef>sd_bus *<parameter>bus</parameter></paramdef> + <paramdef>int <parameter>b</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> + </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 + has been 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 has been 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_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 has been started.</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> + </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> + </refsect1> + + <refsect1> + <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> + </variablelist> + + <variablelist> + <varlistentry> + <term><constant>-ENOPKG</constant></term> + + <listitem><para>The bus cannot be resolved.</para></listitem> + </varlistentry> + </variablelist> + + <variablelist> + <varlistentry> + <term><constant>-EPERM</constant></term> + + <listitem><para>The bus has already been started.</para></listitem> + </varlistentry> + </variablelist> + + <variablelist> + <varlistentry> + <term><constant>-ECHILD</constant></term> + + <listitem><para>The bus was created in a different process.</para></listitem> + </varlistentry> + </variablelist> + + <variablelist> + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</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_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_sender.xml b/man/sd_bus_set_sender.xml new file mode 100644 index 0000000..556e72c --- /dev/null +++ b/man/sd_bus_set_sender.xml @@ -0,0 +1,105 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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_watch_bind.xml b/man/sd_bus_set_watch_bind.xml new file mode 100644 index 0000000..129b98c --- /dev/null +++ b/man/sd_bus_set_watch_bind.xml @@ -0,0 +1,121 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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><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 it is waited 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 is not established yet might block unbounded 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_add_match_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> or + <citerefentry><refentrytitle>sd_bus_request_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> + </refsect1> + + <refsect1> + <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> + </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>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_ref.xml b/man/sd_bus_slot_ref.xml new file mode 100644 index 0000000..c5f0506 --- /dev/null +++ b/man/sd_bus_slot_ref.xml @@ -0,0 +1,107 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + <refname>sd_bus_slot_get_bus</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> + + <funcprototype> + <funcdef>sd_bus *<function>sd_bus_slot_get_bus</function></funcdef> + <paramdef>sd_bus_slot *<parameter>m</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> + + <para><function>sd_bus_slot_get_bus()</function> returns the bus object that message + <parameter>slot</parameter> is attached to.</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> + + <para><function>sd_bus_slot_get_bus()</function> always returns the bus object.</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_slot_new_signal</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..4bcb1e3 --- /dev/null +++ b/man/sd_bus_slot_set_description.xml @@ -0,0 +1,109 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </refsect1> + + <refsect1> + <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> + </variablelist> + + <variablelist> + <varlistentry> + <term><constant>-ENXIO</constant></term> + + <listitem><para>The bus slot object has no description.</para></listitem> + </varlistentry> + </variablelist> + + <variablelist> + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</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_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..80bfd86 --- /dev/null +++ b/man/sd_bus_slot_set_destroy_callback.xml @@ -0,0 +1,131 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </refsect1> + + <refsect1> + <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> + </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..2b8c900 --- /dev/null +++ b/man/sd_bus_slot_set_floating.xml @@ -0,0 +1,118 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </refsect1> + + <refsect1> + <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> + </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..dad708b --- /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.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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_track_add_name.xml b/man/sd_bus_track_add_name.xml new file mode 100644 index 0000000..ef304fc --- /dev/null +++ b/man/sd_bus_track_add_name.xml @@ -0,0 +1,231 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..711eca3 --- /dev/null +++ b/man/sd_bus_track_new.xml @@ -0,0 +1,233 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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-NULL 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> + </refsect1> + + <refsect1> + <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> + </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..e866eeb --- /dev/null +++ b/man/sd_bus_wait.xml @@ -0,0 +1,113 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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> + </refsect1> + + <refsect1> + <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> + </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..c1b38f8 --- /dev/null +++ b/man/sd_event_add_child.xml @@ -0,0 +1,223 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_source_get_child_pid</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_source_get_child_pid</function></funcdef> + <paramdef>sd_event_source *<parameter>source</parameter></paramdef> + <paramdef>pid_t *<parameter>pid</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. 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>If the second parameter of + <function>sd_event_add_child()</function> is passed as NULL 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 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_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> + </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> + </refsect1> + + <refsect1> + <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.</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> + + </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-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 project='man-pages'><refentrytitle>waitid</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..82ddce6 --- /dev/null +++ b/man/sd_event_add_defer.xml @@ -0,0 +1,193 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + NULL 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> + </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> + </refsect1> + + <refsect1> + <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> + </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_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..65765ea --- /dev/null +++ b/man/sd_event_add_inotify.xml @@ -0,0 +1,191 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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 specifie 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 NULL 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><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> + </refsect1> + + <refsect1> + <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> + </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 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..6b3da2b --- /dev/null +++ b/man/sd_event_add_io.xml @@ -0,0 +1,301 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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> + </refsect1> + + <refsect1> + <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> + </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 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..8f03d05 --- /dev/null +++ b/man/sd_event_add_signal.xml @@ -0,0 +1,198 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 will be unblocked by this call, and must be + blocked before this function is called in all threads (using + <citerefentry + project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>). If + the handler is not specified (<parameter>handler</parameter> is + <constant>NULL</constant>), a default handler which causes the + program to exit cleanly will be used.</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><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> + </refsect1> + + <refsect1> + <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> + </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 project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>, + <citerefentry project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</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..e6dbd15 --- /dev/null +++ b/man/sd_event_add_time.xml @@ -0,0 +1,290 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_source_get_time</refname> + <refname>sd_event_source_set_time</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_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_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>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> 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 + used for the exit code passed 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>. 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.</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>. It takes the event + source object and a time relative to the selected clock's epoch, + in µs.</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> + </refsect1> + + <refsect1> + <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> + </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-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 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..2af275b --- /dev/null +++ b/man/sd_event_exit.xml @@ -0,0 +1,139 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </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> + </refsect1> + + <refsect1> + <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> + </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> + </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..5f66fbc --- /dev/null +++ b/man/sd_event_get_fd.xml @@ -0,0 +1,116 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..ddb8dac --- /dev/null +++ b/man/sd_event_new.xml @@ -0,0 +1,223 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..1c8afb2 --- /dev/null +++ b/man/sd_event_now.xml @@ -0,0 +1,122 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..1a44673 --- /dev/null +++ b/man/sd_event_run.xml @@ -0,0 +1,167 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..7d7155d --- /dev/null +++ b/man/sd_event_set_watchdog.xml @@ -0,0 +1,152 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>set_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> + </refsect1> + + <refsect1> + <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> + </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..36e6c1b --- /dev/null +++ b/man/sd_event_source_get_event.xml @@ -0,0 +1,77 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + NULL.</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..75f2690 --- /dev/null +++ b/man/sd_event_source_get_pending.xml @@ -0,0 +1,144 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..be3df3f --- /dev/null +++ b/man/sd_event_source_set_description.xml @@ -0,0 +1,147 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..d9afb4d --- /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.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </refsect1> + + <refsect1> + <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> + </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..73f0184 --- /dev/null +++ b/man/sd_event_source_set_enabled.xml @@ -0,0 +1,158 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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_prepare.xml b/man/sd_event_source_set_prepare.xml new file mode 100644 index 0000000..ae71f74 --- /dev/null +++ b/man/sd_event_source_set_prepare.xml @@ -0,0 +1,149 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 NULL + 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> + </refsect1> + + <refsect1> + <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> + </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..dd16628 --- /dev/null +++ b/man/sd_event_source_set_priority.xml @@ -0,0 +1,172 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..e013282 --- /dev/null +++ b/man/sd_event_source_set_userdata.xml @@ -0,0 +1,96 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + NULL.</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..b11df3f --- /dev/null +++ b/man/sd_event_source_unref.xml @@ -0,0 +1,119 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + + <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> + + </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>.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para><function>sd_event_source_unref()</function> always returns + <constant>NULL</constant>. + <function>sd_event_source_ref()</function> always returns the + event source object passed in.</para> + </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..f01d18e --- /dev/null +++ b/man/sd_event_wait.xml @@ -0,0 +1,332 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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> + </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..925516d --- /dev/null +++ b/man/sd_get_seats.xml @@ -0,0 +1,124 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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-NULL, 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> + </refsect1> + + <refsect1> + <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> + </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_id128_get_machine.xml b/man/sd_id128_get_machine.xml new file mode 100644 index 0000000..0bfe1b5 --- /dev/null +++ b/man/sd_id128_get_machine.xml @@ -0,0 +1,170 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 irreversable (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. In particular, + <function>sd_id128_get_machine()</function>, + <function>sd_id128_get_machine_app_specific()</function>, and + <function>sd_id128_get_boot_app_specific()</function> return <constant>-ENOENT</constant> if + <filename>/etc/machine-id</filename> is missing, and <constant>-ENOMEDIUM</constant> if + <filename>/etc/machine-id</filename> is empty or all zeros.</para> + </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..4f5b160 --- /dev/null +++ b/man/sd_id128_randomize.xml @@ -0,0 +1,82 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..ca07185 --- /dev/null +++ b/man/sd_id128_to_string.xml @@ -0,0 +1,97 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 NULL 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 + <function>SD_ID128_FORMAT_STR</function> 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..05709d8 --- /dev/null +++ b/man/sd_is_fifo.xml @@ -0,0 +1,204 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..d82f71f --- /dev/null +++ b/man/sd_journal_add_match.xml @@ -0,0 +1,180 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..c5704f5 --- /dev/null +++ b/man/sd_journal_enumerate_fields.xml @@ -0,0 +1,136 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..80edc08 --- /dev/null +++ b/man/sd_journal_get_catalog.xml @@ -0,0 +1,116 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..d5e465b --- /dev/null +++ b/man/sd_journal_get_cursor.xml @@ -0,0 +1,117 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..b2a0634 --- /dev/null +++ b/man/sd_journal_get_cutoff_realtime_usec.xml @@ -0,0 +1,117 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..464fd16 --- /dev/null +++ b/man/sd_journal_get_data.xml @@ -0,0 +1,204 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_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>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>. + 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> or + <function>sd_journal_enumerate_data()</function>, or the read + pointer is altered. Note that the data returned will be prefixed + with the field name and '='. 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_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_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. If the current entry + does not include the specified field, -ENOENT is returned. If + <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> + has not been called at least once, -EADDRNOTAVAIL is returned. + <function>sd_journal_enumerate_data()</function> returns a + positive integer if the next field has been read, 0 when no more + fields are known, or a negative errno-style error code. + <function>sd_journal_restart_data()</function> returns nothing. + <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> + </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..2186b68 --- /dev/null +++ b/man/sd_journal_get_fd.xml @@ -0,0 +1,262 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..e0f5c4d --- /dev/null +++ b/man/sd_journal_get_realtime_usec.xml @@ -0,0 +1,115 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..39f53dd --- /dev/null +++ b/man/sd_journal_get_usage.xml @@ -0,0 +1,74 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..44fdc8d --- /dev/null +++ b/man/sd_journal_has_runtime_files.xml @@ -0,0 +1,81 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + Copyright © 2016 Jan Synáček +--> + +<refentry id="sd_journal_has_runtime_files" xmlns:xi="http://www.w3.org/2001/XInclude"> + + <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 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>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..9a27d14 --- /dev/null +++ b/man/sd_journal_next.xml @@ -0,0 +1,178 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.</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..cf787b7 --- /dev/null +++ b/man/sd_journal_open.xml @@ -0,0 +1,205 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_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> + <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_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_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>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</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..e18cf88 --- /dev/null +++ b/man/sd_journal_print.xml @@ -0,0 +1,212 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + <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> + + </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>. + 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 SD_JOURNAL_SUPPRESS_LOCATION before including + <filename>sd-journal.h</filename>.</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 five calls 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> is "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>, and + <function>sd_journal_perror</function> 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..9adafa1 --- /dev/null +++ b/man/sd_journal_query_unique.xml @@ -0,0 +1,159 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_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_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>. + Field names must be specified without a trailing '='. After this + function has been executed successfully the field values may be + queried using <function>sd_journal_enumerate_unique()</function>. + Invoking this call a second time 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 context object, plus a pair of pointers to + pointer/size variables where the data object and its size shall be + 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_unique()</function>. Note that the + data returned will be prefixed with the field name and '='. 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_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_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> returns a + positive integer if the next field data has been read, 0 when no + more fields are known, or a negative errno-style error code. + <function>sd_journal_restart_unique()</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_UNIQUE</function> macro + to iterate through all values a field of the journal can take. 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..da88d24 --- /dev/null +++ b/man/sd_journal_seek_head.xml @@ -0,0 +1,142 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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. 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 most recent + available entry.</para> + + <para><function>sd_journal_seek_monotonic_usec()</function> seeks + to the entry 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 the entry 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 + entry located 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>. + 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..a3ff908 --- /dev/null +++ b/man/sd_journal_stream_fd.xml @@ -0,0 +1,149 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..3c3d2ff --- /dev/null +++ b/man/sd_listen_fds.xml @@ -0,0 +1,233 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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). 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-NULL. 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 NULL 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 + NULL, 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..d914e51 --- /dev/null +++ b/man/sd_login_monitor_new.xml @@ -0,0 +1,251 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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 NULL, 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> + </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..bacbe14 --- /dev/null +++ b/man/sd_machine_get_class.xml @@ -0,0 +1,119 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>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 that is registered with + <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + 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 calls return 0 or a positive integer. On + failure, these calls return a negative errno-style error + code.</para> + </refsect1> + + <refsect1> + <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 NULL, where that is not accepted).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</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-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..79ae84b --- /dev/null +++ b/man/sd_notify.xml @@ -0,0 +1,401 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + <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> + </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_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 maximium 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 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> + + </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><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> + </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> + </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_pid_get_owner_uid.xml b/man/sd_pid_get_owner_uid.xml new file mode 100644 index 0000000..f4619b6 --- /dev/null +++ b/man/sd_pid_get_owner_uid.xml @@ -0,0 +1,321 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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 NULL, where that is not accepted).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</para></listitem> + </varlistentry> + </variablelist> + </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..2fc5fde --- /dev/null +++ b/man/sd_seat_get_active.xml @@ -0,0 +1,178 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_multi_session</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>sessions</parameter></paramdef> + <paramdef>uid_t **<parameter>uid</parameter></paramdef> + <paramdef>unsigned int *<parameter>n_uids</parameter></paramdef> + </funcprototype> + + <funcprototype> + <funcdef>int <function>sd_seat_can_multi_session</function></funcdef> + <paramdef>const char *<parameter>seat</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 the return value, if the latter is nonnegative. + The two arrays and the last parameter may be passed as + <constant>NULL</constant> in case these values need not to be + determined. 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_multi_session()</function> may be used + to determine whether a specific seat is capable of multi-session, + i.e. allows multiple login sessions in parallel (with only one + being active at a time).</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_multi_session</function>, + <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> + </refsect1> + + <refsect1> + <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 NULL, where that is not accepted).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</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-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..a0f7a93 --- /dev/null +++ b/man/sd_session_is_active.xml @@ -0,0 +1,319 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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 NULL, where that is not accepted).</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</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-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..02670e1 --- /dev/null +++ b/man/sd_uid_get_state.xml @@ -0,0 +1,200 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </refsect1> + + <refsect1> + <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 NULL, where that is not accepted). This is also returned if + the passed user ID is 0xFFFF or 0xFFFFFFFF, which are + undefined on Linux.</para></listitem> + </varlistentry> + + <varlistentry> + <term><constant>-ENOMEM</constant></term> + + <listitem><para>Memory allocation failed.</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-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..ad2cdd8 --- /dev/null +++ b/man/sd_watchdog_enabled.xml @@ -0,0 +1,145 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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-NULL, + <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..282a3ba --- /dev/null +++ b/man/shutdown.xml @@ -0,0 +1,151 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + 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..f5c961a --- /dev/null +++ b/man/standard-conf.xml @@ -0,0 +1,78 @@ +<?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+ + 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>, and + <filename>/usr/lib/</filename>, in order of precedence. + Each configuration file in these configuration directories shall be named in + the style of <filename><replaceable>filename</replaceable>.conf</filename>. + Files in <filename>/etc/</filename> override files with the same name in + <filename>/run/</filename> and <filename>/usr/lib/</filename>. Files in + <filename>/run/</filename> override files with the same name in + <filename>/usr/lib/</filename>.</para> + + <para>Packages should install their configuration 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 + 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 option, + the entry in the file with the lexicographically latest name will take + precedence. 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>. 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. 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 which of the subdirectories they reside in. 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. 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..51a4faf --- /dev/null +++ b/man/standard-options.xml @@ -0,0 +1,58 @@ +<?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+ +--> + +<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/sysctl.d.xml b/man/sysctl.d.xml new file mode 100644 index 0000000..7c8fde0 --- /dev/null +++ b/man/sysctl.d.xml @@ -0,0 +1,160 @@ +<?xml version="1.0"?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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> + </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>. + </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> + </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/systemctl.xml b/man/systemctl.xml new file mode 100644 index 0000000..08aacd8 --- /dev/null +++ b/man/systemctl.xml @@ -0,0 +1,2061 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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>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>-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>-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>.</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> or + <literal>flush</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> + + </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>-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 boot into setup + mode. Note that this is currently only supported on some EFI + systems and only if the system was booted in EFI + mode.</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> + + <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>Commands</title> + + <para>The following commands are understood:</para> + + <refsect2> + <title>Unit Commands</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>start <replaceable>PATTERN</replaceable>…</command></term> + + <listitem> + <para>Start (activate) one or more units specified on the + command line.</para> + + <para>Note that glob patterns operate on the set of primary 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> + </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> + </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 is similar to changing the runlevel in a + traditional init system. The <command>isolate</command> + command will immediately stop processes that are not enabled + in the new unit, 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>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 not 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 + by the system and service manager.</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>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 CPUShares=777</command></para> + + <para>If the specified unit appears to be inactive, the + changes will be only stored on disk as described + previously hence they will be effective when the unit will + be started.</para> + + <para>Note that this command allows changing multiple + properties at the same time, which is preferable over + setting them individually. Like with unit file configuration + settings, assigning an empty list will reset the property. + </para> + </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>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> + + <varlistentry> + <term> + <command>list-dependencies</command> + <optional><replaceable>UNIT</replaceable></optional> + </term> + + <listitem> + <para>Shows units required and wanted by the specified + unit. This recursively lists units following the + <varname>Requires=</varname>, + <varname>Requisite=</varname>, + <varname>ConsistsOf=</varname>, + <varname>Wants=</varname>, <varname>BindsTo=</varname> + dependencies. If no unit is 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> + </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 + <literal>[Install]</literal> 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 <literal>[Install]</literal> + 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 <literal>[Install]</literal> 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 <literal>[Install]</literal> 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>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 <literal>[Install]</literal> 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 <literal>[Install]</literal> unit file section, listing other unit files that might be enabled, or it has an alias under a different name through a symlink that is not specified in Also=. For template unit file, an instance different than the one specified in <varname>DefaultInstance=</varname> is enabled.</entry> + <entry>0</entry> + </row> + <row> + <entry><literal>disabled</literal></entry> + <entry>The unit file is not enabled, but contains an <literal>[Install]</literal> 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> + + <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.</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 + no arguments are passed, the entire environment block is + imported. Otherwise, a list of one or more environment + variable names should be passed, whose client-side values + are then imported into the manager's environment + block.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect2> + + <refsect2> + <title>Manager Lifecycle 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> + </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> <optional><replaceable>arg</replaceable></optional></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 optional argument <replaceable>arg</replaceable> is given, it will be passed as the optional + argument to the <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> + system call. 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><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>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"/> + </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..7becf01 --- /dev/null +++ b/man/systemd-analyze.xml @@ -0,0 +1,513 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="systemd-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">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">dump</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">unit-paths</arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">log-level</arg> + <arg choice="opt"><replaceable>LEVEL</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">log-target</arg> + <arg choice="opt"><replaceable>TARGET</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">verify</arg> + <arg choice="opt" rep="repeat"><replaceable>FILES</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>SPECS</replaceable></arg> + </cmdsynopsis> + <cmdsynopsis> + <command>systemd-analyze</command> + <arg choice="opt" rep="repeat">OPTIONS</arg> + <arg choice="plain">service-watchdogs</arg> + <arg choice="opt"><replaceable>BOOL</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">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><command>systemd-analyze time</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> + + <para><command>systemd-analyze blame</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.</para> + + <para><command>systemd-analyze critical-chain + [<replaceable>UNIT…</replaceable>]</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 one service might depend on + socket activation and because of the parallel execution of + units.</para> + + <para><command>systemd-analyze plot</command> prints an SVG + graphic detailing which system services have been started at what + time, highlighting the time they spent on initialization.</para> + + <para><command>systemd-analyze dot</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> + + <para><command>systemd-analyze dump</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> + + <para><command>systemd-analyze cat-config</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> + + <para><command>systemd-analyze unit-paths</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. Note that this verb prints the list that is compiled into + <command>systemd-analyze</command> itself, and does not comunicate with the + running manager. Use + <programlisting>systemctl [--user] [--global] show -p UnitPath --value</programlisting> + to retrieve the actual list that the manager uses, with any empty directories + omitted.</para> + + <para><command>systemd-analyze log-level</command> + prints the current log level of the <command>systemd</command> daemon. + If an optional argument <replaceable>LEVEL</replaceable> is provided, then the command changes the current log + level of the <command>systemd</command> daemon to <replaceable>LEVEL</replaceable> (accepts the same values as + <option>--log-level=</option> described in + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para> + + <para><command>systemd-analyze log-target</command> + prints the current log target of the <command>systemd</command> daemon. + If an optional argument <replaceable>TARGET</replaceable> is provided, then the command changes the current log + target of the <command>systemd</command> daemon to <replaceable>TARGET</replaceable> (accepts the same values as + <option>--log-target=</option>, described in + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</para> + + <para><command>systemd-analyze syscall-filter <optional><replaceable>SET</replaceable>…</optional></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> + + <para><command>systemd-analyze verify</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 (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><command>systemd-analyze calendar</command> will parse and normalize repetitive calendar time events, and + will calculate when they will 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>.</para> + + <para><command>systemd-analyze service-watchdogs</command> + prints the current state of service runtime watchdogs of the <command>systemd</command> daemon. + 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> + + <para><command>systemd-analyze timespan</command> parses a time span and outputs the equivalent value in microseconds, and as a reformatted timespan. + The time span should adhere to the same syntax documented in <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>. + Values without associated magnitudes are parsed as seconds.</para> + + <para><command>systemd-analyze security</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. 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> + + <para>If no command is passed, <command>systemd-analyze + time</command> is implied.</para> + + </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='die-net'><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 man 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> + + <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> + + <refsect1> + <title>Examples for <command>dot</command></title> + + <example> + <title>Plots 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>Plots 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> + </refsect1> + + <refsect1> + <title>Examples for <command>verify</command></title> + + <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> + </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..04f9596 --- /dev/null +++ b/man/systemd-ask-password-console.service.xml @@ -0,0 +1,69 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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://www.freedesktop.org/wiki/Software/systemd/PasswordAgents"> + 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..2fe3e88 --- /dev/null +++ b/man/systemd-ask-password.xml @@ -0,0 +1,216 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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://www.freedesktop.org/wiki/Software/systemd/PasswordAgents">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 NUL-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..a7865b2 --- /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.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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></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..c197b62 --- /dev/null +++ b/man/systemd-binfmt.service.xml @@ -0,0 +1,61 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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> + <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..9809414 --- /dev/null +++ b/man/systemd-bless-boot-generator.xml @@ -0,0 +1,49 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..fb362ce --- /dev/null +++ b/man/systemd-bless-boot.service.xml @@ -0,0 +1,115 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + <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>1</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..55c2adf --- /dev/null +++ b/man/systemd-boot-check-no-failures.service.xml @@ -0,0 +1,54 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + <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>1</manvolnum></citerefentry> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-boot.xml b/man/systemd-boot.xml new file mode 100644 index 0000000..4c914e6 --- /dev/null +++ b/man/systemd-boot.xml @@ -0,0 +1,416 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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. systemd-boot + supports systems with UEFI firmware only.</para> + + <para>systemd-boot loads boot entry information from the EFI system partition (ESP), usually mounted at + <filename>/boot</filename>, <filename>/efi</filename>, or <filename>/boot/efi</filename> during OS + runtime. Configuration file fragments, kernels, initrds and other EFI images to boot generally need to reside on + the ESP. Linux kernels must be built with <option>CONFIG_EFI_STUB</option> to be able to be directly executed as an + EFI image. During boot systemd-boot automatically assembles a list of boot entries from the following + sources:</para> + + <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. 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. + </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><citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry> may be + used to copy kernel images onto the ESP and to generate description files compliant with the Boot Loader + Specification. <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> may be + used from a running system to locate the ESP, list available entries, and install systemd-boot itself.</para> + + <para>systemd-boot will provide information about the time spent in UEFI firmware using the <ulink + url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>. This information can be displayed + using <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </para> + </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> + <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> + <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 used 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>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 systemd-boot reads generally reside on the UEFI ESP which is usually mounted to + <filename>/boot/</filename>, <filename>/efi/</filename> or <filename>/boot/efi</filename> during OS + runtime. systemd-boot 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. 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.</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. These variables are defined by the <ulink + url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>.</para></listitem> + </varlistentry> + </variablelist> + </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 continously 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 end of the list, and entries in 'good' or 'indeterminate' at the beginning. 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 top 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>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..446fa4b --- /dev/null +++ b/man/systemd-cat.xml @@ -0,0 +1,177 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 noindex='true'>/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..0d7f2b6 --- /dev/null +++ b/man/systemd-cgls.xml @@ -0,0 +1,136 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..32ed66b --- /dev/null +++ b/man/systemd-cgtop.xml @@ -0,0 +1,359 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 <varname>--iterations=</varname> 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) + 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..b25f0c4 --- /dev/null +++ b/man/systemd-coredump.xml @@ -0,0 +1,152 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 by 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 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..e30d69b --- /dev/null +++ b/man/systemd-cryptsetup-generator.xml @@ -0,0 +1,183 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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><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.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> + <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> + + <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><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> + </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..439e8e9 --- /dev/null +++ b/man/systemd-cryptsetup@.service.xml @@ -0,0 +1,60 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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://www.freedesktop.org/wiki/Software/systemd/PasswordAgents"> + 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> + </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..fa88e8a --- /dev/null +++ b/man/systemd-debug-generator.xml @@ -0,0 +1,82 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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. It will spawn a debug shell on tty9 during early + system startup. Note that the shell may also be turned on + persistently by enabling it with + <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..f86f205 --- /dev/null +++ b/man/systemd-delta.xml @@ -0,0 +1,181 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..c4763fd --- /dev/null +++ b/man/systemd-detect-virt.xml @@ -0,0 +1,249 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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="11">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>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 valign="top" morerows="5">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>rkt</varname></entry> + <entry>rkt app container runtime</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> + </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-environment-d-generator.xml b/man/systemd-environment-d-generator.xml new file mode 100644 index 0000000..44880e7 --- /dev/null +++ b/man/systemd-environment-d-generator.xml @@ -0,0 +1,56 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> +<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>7</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..f61c07a --- /dev/null +++ b/man/systemd-escape.xml @@ -0,0 +1,185 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..a78e2d5 --- /dev/null +++ b/man/systemd-firstboot.xml @@ -0,0 +1,271 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 host name</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>--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 host name, 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> + + <listitem><para>Sets the password of the system's root user. + This creates a + <citerefentry project='die-net'><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry> + file. This setting exists in two forms: + <option>--root-password=</option> accepts the password to set + directly on the command line, and + <option>--root-password-file=</option> reads it from a file. + Note that it is not recommended to specify 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>--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> + + <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 + and root password. 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> 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> + + <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> 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> + + <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..e1996e4 --- /dev/null +++ b/man/systemd-fsck@.service.xml @@ -0,0 +1,115 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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.*</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..ab70642 --- /dev/null +++ b/man/systemd-fstab-generator.xml @@ -0,0 +1,207 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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></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>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 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> + </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..b5a3006 --- /dev/null +++ b/man/systemd-getty-generator.xml @@ -0,0 +1,74 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/"><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..d98ef20 --- /dev/null +++ b/man/systemd-gpt-auto-generator.xml @@ -0,0 +1,213 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<refentry id="systemd-gpt-auto-generator"> + + <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> and + <filename>/srv</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> 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="http://www.uefi.org/specifications">UEFI Specification</ulink>, chapter 5. + It implements the <ulink + url="https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/">Discoverable + Partitions Specification</ulink>. Note that this generator has no + effect on non-GPT systems, or where the directories under the + mount points are already non-empty. 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 root partitions on the + same physical disk the EFI System Partition (ESP) is located on. + It will only look for the other partitions on the same physical + disk the root file system is located on. 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> 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="explanation" /> + <thead> + <row> + <entry>Partition Type GUID</entry> + <entry>Name</entry> + <entry>Explanation</entry> + </row> + </thead> + <tbody> + <row> + <entry>44479540-f297-41b2-9af7-d131d5f0458a</entry> + <entry><filename>Root Partition (x86)</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>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>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>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>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>933ac7e1-2eb4-4f13-b844-0e14e2aef915</entry> + <entry>Home Partition</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>The first server data partition on the disk the root partition is located on is mounted to <filename>/srv</filename>.</entry> + </row> + <row> + <entry>0657fd6d-a4ab-43c4-84e5-0933c84b4f4f</entry> + <entry>Swap</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>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> + </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>/srv</filename>, <filename>/home</filename></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>/srv</filename>, <filename>/home</filename></entry> + <entry>Partition is not mounted automatically</entry> + </row> + + <row> + <entry><constant>GPT_FLAG_NO_BLOCK_IO_PROTOCOL</constant></entry> + <entry>0x0000000000000002</entry> + <entry>ESP</entry> + <entry>Partition is not mounted automatically</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>The <filename>/home</filename> and <filename>/srv</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> and + <filename>/dev/mapper/srv</filename>. Note that this might create + conflicts if the same partition is listed in + <filename>/etc/crypttab</filename> with a different device mapper + device name.</para> + + <para>Mount and automount units for the EFI System Partition (ESP) are generated on EFI systems. The ESP is mounted + to <filename>/boot</filename>, 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>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>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 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..a40384c --- /dev/null +++ b/man/systemd-halt.service.xml @@ -0,0 +1,96 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..8f0cc5d --- /dev/null +++ b/man/systemd-hibernate-resume-generator.xml @@ -0,0 +1,77 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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>/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>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..0db49e3 --- /dev/null +++ b/man/systemd-hibernate-resume@.service.xml @@ -0,0 +1,57 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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-hostnamed.service.xml b/man/systemd-hostnamed.service.xml new file mode 100644 index 0000000..95c8bb6 --- /dev/null +++ b/man/systemd-hostnamed.service.xml @@ -0,0 +1,61 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>Host name bus mechanism</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</filename> is a system service + that may be used as a mechanism to change the system's hostname. + <filename>systemd-hostnamed</filename> is automatically activated + on request and terminates itself when it is unused.</para> + + <para>The tool + <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + is a command line client to this service.</para> + + <para>See the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/hostnamed"> + developer documentation</ulink> for information about the APIs + <filename>systemd-hostnamed</filename> provides.</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..6c8487a --- /dev/null +++ b/man/systemd-hwdb.xml @@ -0,0 +1,87 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..8a76ccc --- /dev/null +++ b/man/systemd-id128.xml @@ -0,0 +1,122 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + </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> + + <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..ec967c4 --- /dev/null +++ b/man/systemd-importd.service.xml @@ -0,0 +1,58 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 the + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/importd"> + importd D-Bus API Documentation</ulink> for information about the + APIs <filename>systemd-importd</filename> provides.</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..3fa5acf --- /dev/null +++ b/man/systemd-inhibit.xml @@ -0,0 +1,157 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..f9627c9 --- /dev/null +++ b/man/systemd-initctl.service.xml @@ -0,0 +1,52 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="systemd-initctl.service"> + + <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..13604a0 --- /dev/null +++ b/man/systemd-journal-gatewayd.service.xml @@ -0,0 +1,297 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 containing a server + certificate 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 containing a server + key in PEM format corresponding to the certificate specified + with <option>--cert=</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--trust=</option></term> + + <listitem><para>Specify the path to a file containing a + CA certificate 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 + <option>cursor</option> is a cursor string, + <option>num_skip</option> is an integer, + <option>num_entries</option> 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..6e6819b --- /dev/null +++ b/man/systemd-journal-remote.service.xml @@ -0,0 +1,353 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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 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>. + </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>. + </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>. + </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..cdeaddd --- /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.2//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+ +--> + +<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. + 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. + 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>all</option>. If <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>, + <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..9167993 --- /dev/null +++ b/man/systemd-journald.service.xml @@ -0,0 +1,311 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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</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>/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><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>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. The + <command>journalctl --flush</command> command uses this signal + to request flushing of the journal files, and then waits 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. The <command>journalctl --rotate</command> command uses + this signal to request journal file + rotation.</para></listitem> + </varlistentry> + + <varlistentry> + <term>SIGRTMIN+1</term> + + <listitem><para>Request that all unwritten log data is written + to disk. The <command>journalctl --sync</command> command uses + this signal to trigger journal synchronization, and then waits + 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> + </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 logged in user will get their own set of + journal files in <filename>/var/log/journal/</filename>. These + 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 paths that + <command>systemd-journald</command> will listen on that are + visible in the file system. In addition to these, journald can + listen for audit events using netlink.</para></listitem> + </varlistentry> + </variablelist> + </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='die-net'><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..baf20c0 --- /dev/null +++ b/man/systemd-localed.service.xml @@ -0,0 +1,63 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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</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 the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/localed"> + developer documentation</ulink> for information about the APIs + <filename>systemd-localed</filename> provides.</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..1c29b33 --- /dev/null +++ b/man/systemd-logind.service.xml @@ -0,0 +1,106 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/logind"> + logind D-Bus API Documentation</ulink> for information about the + 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> + </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..06e70fc --- /dev/null +++ b/man/systemd-machine-id-commit.service.xml @@ -0,0 +1,73 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + 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..aea13ca --- /dev/null +++ b/man/systemd-machine-id-setup.xml @@ -0,0 +1,154 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">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..b5f3bc2 --- /dev/null +++ b/man/systemd-machined.service.xml @@ -0,0 +1,66 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 virtual machines and containers, and processes + belonging to them.</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>Use + <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry> + to make the names of local containers known to + <command>systemd-machined</command> locally resolvable as host + names.</para> + + <para>See the + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/machined"> + machined D-Bus API Documentation</ulink> for information about the + APIs <filename>systemd-machined</filename> provides.</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..c8e201e --- /dev/null +++ b/man/systemd-makefs@.service.xml @@ -0,0 +1,94 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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-makeswap@.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-makeswap@<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-makeswap@.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.*</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>, + btrfs (see + <citerefentry project='man-pages'><refentrytitle>btrfs-man5</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 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..5aa70b7 --- /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.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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 based on static + configuration.</para> + + <para>See + <citerefentry><refentrytitle>modules-load.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for information about the configuration of this service.</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..610c97f --- /dev/null +++ b/man/systemd-mount.xml @@ -0,0 +1,319 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>). If it is a block device, which is then probed for a label and other + metadata, and is mounted to a directory whose name is generated from the label. In this mode the block device 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 instead of a regular mount point is created (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 yet. 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> + + <xi:include href="standard-options.xml" xpointer="no-pager"/> + <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>, <literal>ext4</literal>, + …). If omitted (or set to <literal>auto</literal>) the file system 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>Takes a boolean argument, defaults to off. This option only has an effect in automount mode, + and controls whether the automount unit shall be bound to the backing device's lifetime. If enabled, the + automount point will be removed automatically when the backing device vanishes. If disabled the automount point + 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>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-networkd-wait-online.service.xml b/man/systemd-networkd-wait-online.service.xml new file mode 100644 index 0000000..95abf5b --- /dev/null +++ b/man/systemd-networkd-wait-online.service.xml @@ -0,0 +1,87 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="systemd-networkd-wait-online.service" conditional='ENABLE_NETWORKD'> + + <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 + gain a carrier.</para> + </refsect1> + + <refsect1> + <title>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>-i</option></term> + <term><option>--interface=</option></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. This option + may be used more than once to wait for multiple network + interfaces. When used, all other interfaces are ignored. + </para></listitem> + </varlistentry> + <varlistentry> + <term><option>--ignore=</option></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>--timeout=</option></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> + </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> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-networkd.service.xml b/man/systemd-networkd.service.xml new file mode 100644 index 0000000..2127bf1 --- /dev/null +++ b/man/systemd-networkd.service.xml @@ -0,0 +1,96 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </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>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> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-notify.xml b/man/systemd-notify.xml new file mode 100644 index 0000000..18d8732 --- /dev/null +++ b/man/systemd-notify.xml @@ -0,0 +1,184 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.</para> + + <para><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> described above.</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 init system about the main PID of + the daemon. Takes a PID as argument. If the argument is + omitted, the PID of the process that invoked + <command>systemd-notify</command> is used. 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> + + <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..ff6b6a9 --- /dev/null +++ b/man/systemd-nspawn.xml @@ -0,0 +1,1303 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ +<!ENTITY fedora_latest_version "28"> +<!ENTITY fedora_cloud_release "1.1"> +]> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">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>-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 copy-on-write scheme — if the file system supports that), which + can be substantially more time-consuming. May not be specified together with <option>--image=</option> or + <option>--ephemeral</option>.</para> + + <para>Note that this switch leaves host name, 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 host name, machine ID and + all other settings that could identify the instance + unmodified.</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://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/">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>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>--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, the root hash is read from it and automatically + used, also as formatted hexadecimal characters.</para></listitem> + </varlistentry> + + <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>--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> + + <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>-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> + + <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>--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. 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 adjusted so that + they are owned to the appropriate UIDs/GIDs selected for the container (see above). This operation is + potentially expensive, as it involves descending and iterating through the full directory tree of the + container. Besides actual file ownership, file ACLs are adjusted as well.</para> + + <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> + + <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 CAP_NET_ADMIN 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-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>--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> + </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>.</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>-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> + + <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> + + <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: + CAP_AUDIT_CONTROL, CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, + CAP_FOWNER, CAP_FSETID, CAP_IPC_OWNER, CAP_KILL, CAP_LEASE, CAP_LINUX_IMMUTABLE, + CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST, CAP_NET_RAW, CAP_SETFCAP, + CAP_SETGID, CAP_SETPCAP, CAP_SETUID, CAP_SYS_ADMIN, CAP_SYS_BOOT, CAP_SYS_CHROOT, + CAP_SYS_NICE, CAP_SYS_PTRACE, CAP_SYS_RESOURCE, CAP_SYS_TTY_CONFIG. Also CAP_NET_ADMIN + is retained if <option>--private-network</option> is specified. If the special value + <literal>all</literal> is passed, all capabilities are retained.</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></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 whitelist (as opposed to a blacklist), + and this command line option hence adds or removes entries from the default whitelist, 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>--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>--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 abrubtly 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>--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> + + <varlistentry> + <term><option>--resolv-conf=</option></term> + + <listitem><para>Configures how <filename>/etc/resolv.conf</filename> inside of the container (i.e. DNS + configuration synchronization from host to container) shall be handled. Takes one of <literal>off</literal>, + <literal>copy-host</literal>, <literal>copy-static</literal>, <literal>bind-host</literal>, + <literal>bind-static</literal>, <literal>delete</literal> or <literal>auto</literal>. 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. If set to <literal>copy-host</literal>, the + <filename>/etc/resolv.conf</filename> file from the host is copied into the container. Similar, if + <literal>bind-host</literal> is used, the file is bind mounted from the host into the container. If set to + <literal>copy-static</literal> the static <filename>resolv.conf</filename> file supplied with + <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> is + copied into the container, and correspondingly <literal>bind-static</literal> bind mounts it there. If set to + <literal>delete</literal> the <filename>/etc/resolv.conf</filename> file in the container is deleted if it + exists. 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 + connectible its static <filename>resolv.conf</filename> file is used, and if not the host's + <filename>/etc/resolv.conf</filename> file is used. In the latter cases the file is copied if the image is + writable, and bind mounted otherwise. It's recommended to use <literal>copy</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. Similar, if <literal>bind</literal> is used, it is bind mounted from the host into the container. If + set to <literal>symlink</literal> a symlink from <filename>/etc/localtime</filename> in the container is + created pointing to the matching the timezone file of 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>--read-only</option></term> + + <listitem><para>Mount the root file system read-only for the + container.</para></listitem> + </varlistentry> + + <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>--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). This option is particularly useful for + mounting directories such as <filename>/var</filename> as + tmpfs, to allow state-less systems, in particular when + combined with <option>--read-only</option>. + Backslash escapes are interpreted in the path, so + <literal>\:</literal> may be used to embed colons in the path. + </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 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 the + <literal>--overlay=+/var::/var</literal> option 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></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>--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> + + <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> + + <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>--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 <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>no</option> (the default), the whole OS tree is made + available writable.</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 enabling this setting will only work correctly with operating systems in the container that can + boot up with only <filename>/usr</filename> mounted, and are able to automatically populate + <filename>/var</filename>, and also <filename>/etc</filename> in case of + <literal>--volatile=yes</literal>.</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> + + <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> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + + </refsect1> + + <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 +# systemd-nspawn -M Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw</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 +# systemd-nspawn -bD /var/lib/machines/f&fedora_latest_version;</programlisting> + + <para>This installs a minimal Fedora distribution into the + directory <filename noindex='true'>/var/lib/machines/f&fedora_latest_version;</filename> + and then boots an OS in a namespace container in it. 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 in a namespace container in it.</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 -d ~/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-path.xml b/man/systemd-path.xml new file mode 100644 index 0000000..b610af6 --- /dev/null +++ b/man/systemd-path.xml @@ -0,0 +1,84 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..8c5e4cc --- /dev/null +++ b/man/systemd-portabled.service.xml @@ -0,0 +1,51 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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-quotacheck.service.xml b/man/systemd-quotacheck.service.xml new file mode 100644 index 0000000..c7cf237 --- /dev/null +++ b/man/systemd-quotacheck.service.xml @@ -0,0 +1,70 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..dc5c884 --- /dev/null +++ b/man/systemd-random-seed.service.xml @@ -0,0 +1,51 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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 restores the random seed of the system at early boot + and saves it at shutdown. See + <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> + for details. Saving/restoring the random seed across boots + increases the amount of available entropy early at boot. On disk + the random seed is stored in + <filename>/var/lib/systemd/random-seed</filename>.</para> + </refsect1> + + <refsect1> + <title>See Also</title> + <para> + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + <citerefentry><refentrytitle>random</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..3474a8f --- /dev/null +++ b/man/systemd-rc-local-generator.xml @@ -0,0 +1,60 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<refentry id="systemd-rc-local-generator"> + + <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>/etc/rc.local</filename> and <filename>/usr/sbin/halt.local</filename> during boot and shutdown</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>/etc/rc.local</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><filename>systemd-rc-local-generator</filename> also checks whether <filename>/usr/sbin/halt.local</filename> + exists and is executable, and if it is pulls the <filename>halt-local.service</filename> unit into the shutdown + process. This unit is responsible for running this script during later shutdown.</para> + + <para>Support for both <filename>/etc/rc.local</filename> and <filename>/usr/sbin/halt.local</filename> is provided + for compatibility with specific System V systems only. However, it is strongly recommended to avoid making use of + these scripts today, and instead provide proper unit files with appropriate dependencies for any scripts to run + during the boot or shutdown processes.</para> + + <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..988a617 --- /dev/null +++ b/man/systemd-remount-fs.service.xml @@ -0,0 +1,64 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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> + 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 listed in + <filename>/etc/fstab</filename>. 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 <filename>/etc/fstab</filename> + does not exist or lists no entries for the mentioned file + systems.</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> + </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> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd-resolved.service.xml b/man/systemd-resolved.service.xml new file mode 100644 index 0000000..d7334e0 --- /dev/null +++ b/man/systemd-resolved.service.xml @@ -0,0 +1,288 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 the + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/resolved">API Documentation</ulink> 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 host names 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, user request made 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> synthesizes 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) 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).</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>Lookups for the special hostname <literal>localhost</literal> are never routed to the network. (A + few other, special domains are handled the same way.)</para></listitem> + + <listitem><para>Single-label names are routed to all local interfaces capable of IP multicasting, using the LLMNR + protocol. Lookups for IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are only + sent via LLMNR on IPv6. Lookups for the locally configured host name and the <literal>_gateway</literal> host + name are never routed to LLMNR.</para></listitem> + + <listitem><para>Multi-label names with the domain suffix <literal>.local</literal> are routed to all local + interfaces capable of IP multicasting, using the MulticastDNS protocol. As with LLMNR IPv4 address lookups are + sent via IPv4 and IPv6 address lookups are sent via IPv6.</para></listitem> + + <listitem><para>Other multi-label names are routed to all local interfaces that have a DNS server configured, + plus the globally configured DNS server if there is one. Address lookups from the link-local address range are + never routed to DNS. 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 within this + DNS domain work. Note that today 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> + </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 may be influenced by configuring per-interface domain names and other settings. See + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> and + <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details. 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 search + or route-only domains of any link (or the globally configured DNS settings), the "best matching" + search/route-only 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" + search/route-only domain. (Note that more than one link might have this same "best matching" search/route-only + domain configured, in which case the query is sent to all of them in parallel).</para></listitem> + + <listitem><para>If a query does not match any configured search/route-only domain (neither per-link nor global), + it is sent to all DNS servers that are configured on links with the "DNS default route" option set, as well as + the globally configured DNS server.</para></listitem> + + <listitem><para>If there is no link configured as "DNS default route" and no global DNS server configured, the + compiled-in fallback DNS server is used.</para></listitem> + + <listitem><para>Otherwise the query is failed as no suitable DNS servers could be determined.</para></listitem> + </itemizedlist> + + <para>The "DNS default route" option is a boolean setting configureable with <command>resolvectl</command> or in + <filename>.network</filename> files. If not set, it is implicitly determined based on the configured DNS domains + for a link: if there's any route-only domain (not matching <literal>~.</literal>) it defaults to false, otherwise + to true.</para> + + <para>Effectively this means: in order to preferably route all DNS queries not explicitly matched by + search/route-only 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 the queries (unless they too carry such a + route-only domain). In order to route all such DNS queries to a specific link only in case no other link is + preferable, then set the "DNS default route" 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 search/route-only domains, set the "DNS default route" option for it + to false.</para> + + <para>See the <ulink url="https://www.freedesktop.org/wiki/Software/systemd/resolved"> resolved D-Bus API + Documentation</ulink> for information about the APIs <filename>systemd-resolved</filename> provides.</para> + </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..d8c2ee2 --- /dev/null +++ b/man/systemd-rfkill.service.xml @@ -0,0 +1,66 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..20eb691 --- /dev/null +++ b/man/systemd-run-generator.xml @@ -0,0 +1,82 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..3c60340 --- /dev/null +++ b/man/systemd-run.xml @@ -0,0 +1,515 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + + <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>.</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>--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, a non-zero failure + code otherwise.</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 +-- Logs begin at Fri 2014-12-05 19:09:21 KST, end 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 +-- Logs begin at Fri 2014-12-05 19:09:21 KST, end 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> + </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..af61947 --- /dev/null +++ b/man/systemd-sleep.conf.xml @@ -0,0 +1,206 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>5</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 + <literal>[Sleep]</literal> 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 in seconds + that will pass before the system is automatically + put into hibernate when using + <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </para></listitem> + </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..c370705 --- /dev/null +++ b/man/systemd-socket-activate.xml @@ -0,0 +1,184 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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_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..1869465 --- /dev/null +++ b/man/systemd-socket-proxyd.xml @@ -0,0 +1,176 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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> + </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> + </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..cef7adb --- /dev/null +++ b/man/systemd-suspend.service.xml @@ -0,0 +1,130 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>, and + <filename>systemd-hybrid-sleep.service</filename> + <filename>systemd-suspend-then-hibernate.service</filename> + should never be executed directly. Instead, trigger system sleep + states with a command such as <literal>systemctl suspend</literal> + or similar.</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 <literal>[Sleep]</literal> 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..2712402 --- /dev/null +++ b/man/systemd-sysctl.service.xml @@ -0,0 +1,130 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..a7b62b5 --- /dev/null +++ b/man/systemd-system-update-generator.xml @@ -0,0 +1,51 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..27242b3 --- /dev/null +++ b/man/systemd-system.conf.xml @@ -0,0 +1,385 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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>5</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 + <literal>[Manager]</literal> section:</para> + + <variablelist class='config-directives'> + + <varlistentry> + <term><varname>LogLevel=</varname></term> + <term><varname>LogTarget=</varname></term> + <term><varname>LogColor=</varname></term> + <term><varname>LogLocation=</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. 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>RuntimeWatchdogSec=</varname></term> + <term><varname>ShutdownWatchdogSec=</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>ShutdownWatchdogSec=</varname> may be used to configure the + hardware watchdog when the system is asked to reboot. It works as a safety net to ensure that the reboot takes + place even if a clean reboot attempt times out. Note that the <varname>ShutdownWatchdogSec=</varname> timeout + applies only to the second phase of the reboot, i.e. after all regular services are already terminated, and + after the system and service manager process (PID 1) got replaced by the <filename>systemd-shutdown</filename> + binary, see system <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details. During the first phase of the shutdown operation the system and service manager remains running + and hence <varname>RuntimeWatchdogSec=</varname> is still honoured. In order to define a timeout on this first + phase of system shutdown, configure <varname>JobTimeoutSec=</varname> and <varname>JobTimeoutAction=</varname> + in the <literal>[Unit]</literal> section of the <filename>shutdown.target</filename> unit. By default + <varname>RuntimeWatchdogSec=</varname> defaults to 0 (off), and <varname>ShutdownWatchdogSec=</varname> to + 10min. These settings have no effect if a hardware watchdog is not available.</para></listitem> + </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>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>DefaultRestartSec=</varname></term> + + <listitem><para>Configures the default timeouts for starting + and stopping of units, as well as the default time to sleep + between automatic restarts of units, as configured per-unit in + <varname>TimeoutStartSec=</varname>, + <varname>TimeoutStopSec=</varname> and + <varname>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>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%, which equals 4915 with the kernel's defaults on the host, but might be 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 units. See + <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> + for details. The resource limit is possible to specify in two formats, + <option>value</option> to set soft and hard limits to the same value, + or <option>soft:hard</option> to set both limits individually (e.g. DefaultLimitAS=4G:16G). + Use the string <varname>infinity</varname> to + configure no limit on a specific resource. The multiplicative + suffixes K (=1024), M (=1024*1024) and so on for G, T, P and E + may be used for resource limits measured in bytes + (e.g. DefaultLimitAS=16G). For the limits referring to time values, + the usual time units ms, s, min, h and so on may be used (see + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> + for details). Note that if no time unit is specified for + <varname>DefaultLimitCPU=</varname> the default unit of seconds is + implied, while for <varname>DefaultLimitRTTIME=</varname> the default + unit of microseconds is implied. Also, note that the effective + granularity of the limits might influence their + enforcement. For example, time limits specified for + <varname>DefaultLimitCPU=</varname> will be rounded up implicitly to + multiples of 1s. These settings may be overridden in individual units + using the corresponding LimitXXX= directives. Note that these resource + limits are only defaults for units, they are not applied to PID 1 + itself.</para></listitem> + </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..6c9b921 --- /dev/null +++ b/man/systemd-sysusers.xml @@ -0,0 +1,138 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>--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 from, 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..0b07cc3 --- /dev/null +++ b/man/systemd-sysv-generator.xml @@ -0,0 +1,73 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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>5</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..5667c88 --- /dev/null +++ b/man/systemd-time-wait-sync.service.xml @@ -0,0 +1,71 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 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 servies 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..e334e8a --- /dev/null +++ b/man/systemd-timedated.service.xml @@ -0,0 +1,82 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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</filename> is a system service + that may be used as a mechanism to change the system clock and + timezone, as well as to enable/disable NTP time synchronization. + <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>See the <ulink + url="https://www.freedesktop.org/wiki/Software/systemd/timedated"> + developer documentation</ulink> for information about the APIs + <filename>systemd-timedated</filename> provides.</para> + </refsect1> + + <refsect1> + <title>Environment</title> + + <variablelist class='environment-variables'> + <varlistentry> + <term><varname>$SYSTEMD_TIMEDATED_NTP_SERVICES</varname></term> + + <listitem><para>Colon-separated list of unit names of NTP client services. + If not set, then + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + is used. See the entries of NTP related commands of + <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + for details about this.</para> + + <para>Example: + <programlisting>SYSTEMD_TIMEDATED_NTP_SERVICES=ntpd.service:chronyd.service:systemd-timesyncd.service</programlisting> + </para></listitem> + </varlistentry> + </variablelist> + </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..cdea106 --- /dev/null +++ b/man/systemd-timesyncd.service.xml @@ -0,0 +1,107 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..9978d95 --- /dev/null +++ b/man/systemd-tmpfiles.xml @@ -0,0 +1,222 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </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>--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>Note that this option does not alter how the users and groups specified in the configuration files are + resolved. With or without this option, users and groups are always resolved according to the host's user and + group databases, any such databases stored under the specified root directories are not + consulted.</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 clean-up 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..75ab032 --- /dev/null +++ b/man/systemd-tty-ask-password-agent.xml @@ -0,0 +1,129 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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://www.freedesktop.org/wiki/Software/systemd/PasswordAgents">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-udevd.service.xml b/man/systemd-udevd.service.xml new file mode 100644 index 0000000..330700d --- /dev/null +++ b/man/systemd-udevd.service.xml @@ -0,0 +1,206 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>-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 starting with "rd." will be read when + <command>systemd-udevd</command> is used in an initrd.</para> + <varlistentry> + <term><varname>udev.log_priority=</varname></term> + <term><varname>rd.udev.log_priority=</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>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). The names are derived from various + device metadata fields. Newer versions of <filename>systemd-udevd.service</filename> take more of + these fields into account, improving (and thus possibly changing) the names used for the same + devices. With this kernel command line option it is possible to pick a specific version of this + algorithm. It expects a naming scheme identifier as argument. Currently the following identifiers + are known: <literal>v238</literal>, <literal>v239</literal>, <literal>v240</literal> which each + implement the naming scheme that was the default in the indicated systemd version. In addition, + <literal>latest</literal> may be used to designate the latest scheme known (to this particular + version of <filename>systemd-udevd.service</filename>).</para> + + <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..fa88e66 --- /dev/null +++ b/man/systemd-update-done.service.xml @@ -0,0 +1,73 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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> + + </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..a3822ac --- /dev/null +++ b/man/systemd-update-utmp.service.xml @@ -0,0 +1,52 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..52fc0d7 --- /dev/null +++ b/man/systemd-user-sessions.service.xml @@ -0,0 +1,51 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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-vconsole-setup.service.xml b/man/systemd-vconsole-setup.service.xml new file mode 100644 index 0000000..08c5d81 --- /dev/null +++ b/man/systemd-vconsole-setup.service.xml @@ -0,0 +1,64 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..f9f645f --- /dev/null +++ b/man/systemd-veritysetup-generator.xml @@ -0,0 +1,98 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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 se 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 use 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..7701409 --- /dev/null +++ b/man/systemd-veritysetup@.service.xml @@ -0,0 +1,51 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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..651832f --- /dev/null +++ b/man/systemd-volatile-root.service.xml @@ -0,0 +1,55 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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.automount.xml b/man/systemd.automount.xml new file mode 100644 index 0000000..2e55ad0 --- /dev/null +++ b/man/systemd.automount.xml @@ -0,0 +1,164 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 noindex='true'>/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> + </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> + </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..0144704 --- /dev/null +++ b/man/systemd.device.xml @@ -0,0 +1,168 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + <literal>[Unit]</literal> and <literal>[Install]</literal> + sections. A separate <literal>[Device]</literal> 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 noindex='true'>/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..dc00591 --- /dev/null +++ b/man/systemd.dnssd.xml @@ -0,0 +1,234 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- +--> + +<refentry id="systemd.dnssd" 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 directory <filename>/usr/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>. Drop-in files under any of these + directories take precedence over the main network service 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>[Service] Section Options</title> + + <para>The network service file contains a <literal>[Service]</literal> + 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> + <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> + <row> + <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> + <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> + <entry><literal>%H</literal></entry> + <entry>Host name</entry> + <entry>The hostname of the running system.</entry> + </row> + <row> + <entry><literal>%v</literal></entry> + <entry>Kernel release</entry> + <entry>Identical to <command>uname -r</command> output.</entry> + </row> + </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..4595a99 --- /dev/null +++ b/man/systemd.environment-generator.xml @@ -0,0 +1,137 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..0248c3a --- /dev/null +++ b/man/systemd.exec.xml @@ -0,0 +1,2903 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="systemd.exec"> + <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>Similar, 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>, + <option>syslog</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> + </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></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://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/">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></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></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></listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1> + <title>Credentials</title> + + <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 restrictions on the user/group name syntax are enforced: 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. These restrictions + are enforced in order to avoid ambiguities and to ensure user/group names and unit files remain portable among + Linux systems.</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.</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>, + <varname>PrivateTmp=</varname> are implied. This ensures that the lifetime of IPC objects and temporary files + created by the executed processes is bound to the runtime of the service, and hence the lifetime of the dynamic + user/group. Since <filename>/tmp</filename> and <filename>/var/tmp</filename> are usually the only + world-writable directories on a system this ensures that a unit making use of dynamic user/group allocation + cannot leave files around after unit termination. Moreover <varname>ProtectSystem=strict</varname> and + <varname>ProtectHome=read-only</varname> are implied, thus prohibiting the service to write to arbitrary file + system locations. In order to allow the service to write to certain directories, they have to be whitelisted + using <varname>ReadWritePaths=</varname>, but care must be taken so that 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). 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> + + <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>Example: if a unit has the following, + <programlisting>CapabilityBoundingSet=CAP_A CAP_B +CapabilityBoundingSet=CAP_B CAP_C</programlisting> + then <constant>CAP_A</constant>, <constant>CAP_B</constant>, and <constant>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>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>MemoryDenyWriteExecute=</varname>, <varname>RestrictRealtime=</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> + <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. This result in a non + operation if AppArmor is not enabled. If prefixed by <literal>-</literal>, all errors will be ignored. This + 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. LimitAS=16G). For the limits referring to time values, + the usual time units ms, s, min, h and so on may be used (see + <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for + details). Note that if no time unit is specified for <varname>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>MemoryLimit=</varname> is a more powerful (and working) + replacement for <varname>LimitRSS=</varname>.</para> + + <para>For system units these resource limits may be chosen freely. For user units however (i.e. units run by a + per-user instance of + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>), these limits are + bound by (possibly more restrictive) per-user limits enforced by the OS.</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 above).</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.</para></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 level for the Out-Of-Memory killer for executed processes. Takes an integer + between -1000 (to disable OOM killing for this process) and 1000 (to make killing of this process under memory + pressure very likely). See <ulink + url="https://www.kernel.org/doc/Documentation/filesystems/proc.txt">proc.txt</ulink> for + details.</para></listitem> + </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><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><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 fork, and can hence not leak into child processes. See + <citerefentry><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. 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><refentrytitle>sched_setaffinity</refentrytitle><manvolnum>2</manvolnum></citerefentry> for + details.</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.</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 <filename>/boot</filename> + directories 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 necessary directories + are still visible by combining with <varname>BindPaths=</varname> or <varname>BindReadOnlyPaths=</varname>.</para> + + <para>Setting this to <literal>yes</literal> is mostly equivalent to set the three directories in + <varname>InaccessiblePaths=</varname>. Similarly, <literal>read-only</literal> is mostly equivalent to + <varname>ReadOnlyPaths=</varname>, and <literal>tmpfs</literal> is mostly equivalent to + <varname>TemporaryFileSystem=</varname>.</para> + + <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></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, one or more + directories by the specified names will be created (including their parents) below the locations + defined in the following table, when the unit is started. Also, the corresponding environment variable + is defined with the full path of 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>Locations</entry> + <entry>for system</entry> + <entry>for users</entry> + <entry>Environment variable</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 lowest 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>, + <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>Example: if a system service unit has the following, + <programlisting>RuntimeDirectory=foo/bar baz</programlisting> + the service manager creates <filename>/run/foo</filename> (if it does not exist), + <filename>/run/foo/bar</filename>, and <filename>/run/baz</filename>. The directories + <filename>/run/foo/bar</filename> and <filename>/run/baz</filename> except <filename>/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>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 might have to the file system hierarchy. 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 whitelist + 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></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>. See the example below.</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></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 is 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></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></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></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>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>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></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></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></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 whitelist, 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 blacklist, otherwise as whitelist. 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, pcc64, 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 familiy 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 whitelist 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 (whitelisting). 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 (blacklisting). 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>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></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></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 namepace 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 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> + </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 (whitelisting). If the first character of the list is <literal>~</literal>, + the effect is inverted: only the listed system calls will result in immediate process termination + (blacklisting). Blacklisted system calls and system call groups may optionally be suffixed with a colon + (<literal>:</literal>) and <literal>errno</literal> error number (between 0 and 4095) or errno name such as + <constant>EPERM</constant>, <constant>EACCES</constant> or <constant>EUCLEAN</constant>. This value will be + returned when a blacklisted system call is triggered, instead of terminating the processes immediately. This + value takes precedence over the one given in <varname>SystemCallErrorNumber=</varname>. If running in user + mode, or in system mode, but without the <constant>CAP_SYS_ADMIN</constant> capability (e.g. setting + <varname>User=nobody</varname>), <varname>NoNewPrivileges=yes</varname> is implied. This feature makes use of + the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is useful for enforcing a + minimal sandboxing environment. Note that the <function>execve</function>, <function>exit</function>, + <function>exit_group</function>, <function>getrlimit</function>, <function>rt_sigreturn</function>, + <function>sigreturn</function> system calls and the system calls for querying time and sleeping are implicitly + whitelisted and do not need to be listed explicitly. This option may be specified more than once, in which case + the filter masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will + have no effect. This does not affect commands prefixed with <literal>+</literal>.</para> + + <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. whitelisting and blacklisting), 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 a whitelisting of + <function>read</function> and <function>write</function>, and right after it add a blacklisting of + <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 into 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, namespaceing 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 whitelisting 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> + </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, whitelisting system calls (rather than blacklisting) is the safer mode of operation. It is + recommended to enforce system call whitelists 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>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>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. When this setting is not used, or when the empty string is assigned, the process will + be terminated immediately when the filter is triggered.</para></listitem> + </varlistentry> + + <varlistentry> + <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 + system call architecture 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> + + </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 $ + 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>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.</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>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).</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>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 <citerefentry + project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details + 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> + + <para>Note that services which specify <option>DefaultDependencies=no</option> and use + <varname>StandardInput=</varname> or <varname>StandardOutput=</varname> with + <option>tty</option>/<option>tty-force</option>/<option>tty-fail</option>, should specify + <option>After=systemd-vconsole-setup.service</option>, to make sure that the tty intialization is + finished before they start.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>StandardOutput=</varname></term> + + <listitem><para>Controls where file descriptor 1 (STDOUT) of the executed processes is connected to. Takes one + of <option>inherit</option>, <option>null</option>, <option>tty</option>, <option>journal</option>, + <option>syslog</option>, <option>kmsg</option>, <option>journal+console</option>, + <option>syslog+console</option>, <option>kmsg+console</option>, + <option>file:<replaceable>path</replaceable></option>, <option>append:<replaceable>path</replaceable></option>, + <option>socket</option> or <option>fd:<replaceable>name</replaceable></option>.</para> + + <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 syslog or kmsg (see below) is implicitly stored in the journal as well, the + specific two options listed below are hence supersets of this one.</para> + + <para><option>syslog</option> connects standard output to the <citerefentry + project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> system syslog + service, in addition to the journal. Note that the journal daemon is usually configured to forward everything + it receives to syslog anyway, in which case this option is no different from <option>journal</option>.</para> + + <para><option>kmsg</option> connects standard output with the kernel log buffer which is accessible via + <citerefentry project='man-pages'><refentrytitle>dmesg</refentrytitle><manvolnum>1</manvolnum></citerefentry>, + in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which + case this option is no different from <option>journal</option>.</para> + + <para><option>journal+console</option>, <option>syslog+console</option> and <option>kmsg+console</option> work + in a similar way as the three options above but copy the output to the system console as well.</para> + + <para>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, syslog or the + kernel log buffer, the unit will implicitly gain a dependency of type <varname>After=</varname> on + <filename>systemd-journald.socket</filename> (also see the "Implicit Dependencies" section above). Also note + that in this case stdout (or stderr, see below) will be an <constant>AF_UNIX</constant> stream socket, and not + a pipe or FIFO that can be re-opened. This means when executing shell scripts the construct <command>echo + "hello" > /dev/stderr</command> for writing text to stderr will not work. To mitigate this use the construct + <command>echo "hello" >&2</command> instead, which is mostly equivalent and avoids this pitfall.</para> + + <para>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 ("). 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>SyslogIdentifier=</varname></term> + + <listitem><para>Sets the process name ("<command>syslog</command> tag") to prefix log lines sent to the logging + system or the kernel log buffer with. If not set, defaults to the process name of the executed process. This + option is only useful when <varname>StandardOutput=</varname> or <varname>StandardError=</varname> are set to + <option>journal</option>, <option>syslog</option> or <option>kmsg</option> (or to the same settings in + combination with <option>+console</option>) and only applies to log messages written to stdout or + stderr.</para></listitem> + </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>, <option>syslog</option> or + <option>kmsg</option> (or to the same settings in combination with <option>+console</option>), and only applies + to log messages written to stdout or stderr. Defaults to <option>daemon</option>.</para></listitem> + </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>, <option>syslog</option> or + <option>kmsg</option> (or to the same settings in combination with <option>+console</option>), and only applies + to log messages written to stdout or stderr. 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>, <option>syslog</option> or + <option>kmsg</option> (or to the same settings in combination with <option>+console</option>), log lines + written by the executed process that are prefixed with a log level will be processed with this log level set + but the prefix removed. If set to false, the interpretation of these prefixes is disabled and the logged lines + are passed on as-is. This only applies to log messages written to stdout or stderr. For details about this + prefixing see <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>. + 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>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> (see + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) or via + <command>systemctl set-environment</command> (see <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>).</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 variables are set by multiple of these sources, the later source — according to the + order of the list above — wins. Note that as final step all variables listed in + <varname>UnsetEnvironment=</varname> are removed again from the compiled environment variable list, immediately + before it is passed to the executed process.</para> + + <para>The following select environment variables are set or propagated by the service manager 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. systemd uses a fixed value of + <filename>/usr/local/sbin</filename>:<filename>/usr/local/bin</filename>:<filename>/usr/sbin</filename>:<filename>/usr/bin</filename>:<filename>/sbin</filename>:<filename>/bin</filename>. + </para></listitem> + </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>$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>$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 valign="top"><literal>success</literal></entry> + <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><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> + </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> + </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> + </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> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml new file mode 100644 index 0000000..5007563 --- /dev/null +++ b/man/systemd.generator.xml @@ -0,0 +1,318 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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>/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>It is a good idea to use the <varname>SourcePath=</varname> directive + in generated unit files to specify the source configuration file you are + generating the unit 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.</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.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..76e1de7 --- /dev/null +++ b/man/systemd.journal-fields.xml @@ -0,0 +1,550 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 resemble an environment block in + their syntax but with fields that can include binary data. + Primarily, fields are formatted UTF-8 text strings, and binary + formatting 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 meaning. 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>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> + </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> + </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_SESSION=</varname></term> + <term><varname>_SYSTEMD_OWNER_UID=</varname></term> + + <listitem> + <para>The control group path in the systemd hierarchy, the + 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 NUL 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>) or + <option>eof</option> (if this was the last log record of a stream and the stream ended without a final + newline character). Note that this record is not generated when a normal newline character was used for + marking the log line end.</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, the major and minor of the device node, + separated by <literal>:</literal> and prefixed by + <literal>b</literal>. Similar 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>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..1b4a4a8 --- /dev/null +++ b/man/systemd.kill.xml @@ -0,0 +1,192 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>process</option>, + <option>mixed</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>process</option>, only the main process itself is + killed. 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>none</option>, no + process is killed. In this case, only the stop command will be + executed on unit stop, but no process be killed otherwise. + Processes remaining alive after stop are left in their control + group and the control group continues to exist after stop + unless it is empty.</para> + + <para>Processes will first be terminated via + <constant>SIGTERM</constant> (unless the signal to send is + changed via <varname>KillSignal=</varname>). Optionally, this + is immediately followed by a <constant>SIGHUP</constant> (if + enabled with <varname>SendSIGHUP=</varname>). If then, after a + delay (configured via the <varname>TimeoutStopSec=</varname> + option), processes still remain, 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 killing 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>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. 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..178f9b8 --- /dev/null +++ b/man/systemd.link.xml @@ -0,0 +1,687 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>Network link configuration is performed by the + <command>net_setup_link</command> udev builtin.</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 each of the entries in the [Match] section matches, or if + the section is empty. The following keys are accepted:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>A whitespace-separated list of hardware addresses. Use full colon-, hyphen- or dot-delimited hexadecimal. See the example below. + This option may appear more than 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> + <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> + <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> + <term><varname>Driver=</varname></term> + <listitem> + <para>A whitespace-separated list of shell-style globs matching the driver currently bound to the + device, as exposed by the udev property <varname>DRIVER</varname> of its parent device, or if that + is not set, the driver as exposed by <command>ethtool -i</command> of the device itself.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Type=</varname></term> + <listitem> + <para>A whitespace-separated list of shell-style globs matching + the device type, as exposed by the udev + property <varname>DEVTYPE</varname>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Host=</varname></term> + <listitem> + <para>Matches against the hostname or machine + ID of the host. See <varname>ConditionHost=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</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 + <varname>ConditionVirtualization=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KernelCommandLine=</varname></term> + <listitem> + <para>Checks whether a specific kernel command line option + is set (or if prefixed with the exclamation mark unset). See + <varname>ConditionKernelCommandLine=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details.</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 (or if prefixed with the exclamation mark does not match it). See + <varname>ConditionKernelVersion=</varname> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. + </para> + </listitem> + </varlistentry> + <varlistentry> + <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.</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.</para> + </listitem> + </varlistentry> + </variablelist> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>The MAC address to use, if no + <varname>MACAddressPolicy=</varname> + is specified.</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 udev 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>. + </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>. + </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>.</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>.</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 in case all the + policies specified in + <varname>NamePolicy=</varname> fail, or in case + <varname>NamePolicy=</varname> is missing or + disabled.</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>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 autonegotation 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>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> + </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> + </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..61e97b1 --- /dev/null +++ b/man/systemd.mount.xml @@ -0,0 +1,545 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + noindex='true'>/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> + </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></listitem> + </varlistentry> + + <varlistentry> + <term><option>x-systemd.before=</option></term> + <term><option>x-systemd.after=</option></term> + + <listitem><para>Configures a <varname>Before=</varname> + dependency or <varname>After=</varname> between the created + mount unit and 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></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 initalized.</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>_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>%%</literal>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>Where=</varname></term> + <listitem><para>Takes an absolute path of a 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. 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>%%</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>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> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml new file mode 100644 index 0000000..74281f2 --- /dev/null +++ b/man/systemd.netdev.xml @@ -0,0 +1,1680 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>Network setup is performed by + <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </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.Local configuration</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>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>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>netdevsim</varname></entry> + <entry> A simulator. This simulated networking device is used for testing various networking APIs and at this time is particularly focused on testing hardware offloading related interfaces.</entry></row> + + <row><entry><varname>fou</varname></entry> + <entry>Foo-over-UDP tunneling.</entry></row> + + </tbody> + </tgroup> + </table> + + </refsect1> + + <refsect1> + <title>[Match] Section Options</title> + + <para>A virtual network device is only created if the + <literal>[Match]</literal> 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. + </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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KernelCommandLine=</varname></term> + <listitem> + <para>Checks whether a specific kernel command line option + is set (or if prefixed with the exclamation mark unset). See + <literal>ConditionKernelCommandLine=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. + </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 (or if prefixed with the exclamation mark does not match it). See + <literal>ConditionKernelVersion=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details. + </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. + </para> + </listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>[NetDev] Section Options</title> + + <para>The <literal>[NetDev]</literal> section accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Description=</varname></term> + <listitem> + <para>A free-form description of the netdev.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Name=</varname></term> + <listitem> + <para>The interface name used when creating the netdev. + This option is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Kind=</varname></term> + <listitem> + <para>The netdev kind. This option is compulsory. See the + <literal>Supported netdev kinds</literal> section for the + valid keys.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MTUBytes=</varname></term> + <listitem> + <para>The maximum transmission unit in bytes to set for the device. The usual suffixes K, M, G, + are supported and are understood to the base of 1024. For <literal>tun</literal> or + <literal>tap</literal> devices, <varname>MTUBytes=</varname> setting is not currently supported in + <literal>[NetDev]</literal> section. Please specify it in <literal>[Link]</literal> section of + corresponding + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + files.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>The MAC address to use for the device. For <literal>tun</literal> or <literal>tap</literal> + devices, setting <varname>MACAddress=</varname> in the <literal>[NetDev]</literal> section is not + supported. Please specify it in <literal>[Link]</literal> section of the corresponding + <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> + file. If this option is not set, <literal>vlan</literal> devices inherit the MAC address of the + physical interface. For other kind of netdevs, if this option is not set, then MAC address is + generated based on the interface name and the + <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Bridge] Section Options</title> + + <para>The <literal>[Bridge]</literal> section only applies for + netdevs of kind <literal>bridge</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>HelloTimeSec=</varname></term> + <listitem> + <para>HelloTimeSec specifies the number of seconds between two hello packets + sent out by the root bridge and the designated bridges. Hello packets are + used to communicate information about the topology throughout the entire + bridged local area network.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MaxAgeSec=</varname></term> + <listitem> + <para>MaxAgeSec specifies the number of seconds of maximum message age. + If the last seen (received) hello packet is more than this number of + seconds old, the bridge in question will start the takeover procedure + in attempt to become the Root Bridge itself.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ForwardDelaySec=</varname></term> + <listitem> + <para>ForwardDelaySec specifies the number of seconds spent in each + of the Listening and Learning states before the Forwarding state is entered.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>AgeingTimeSec=</varname></term> + <listitem> + <para>This specifies the number of seconds a MAC Address will be kept in + the forwarding database after having a packet received from this MAC Address.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Priority=</varname></term> + <listitem> + <para>The priority of the bridge. An integer between 0 and 65535. A lower value + means higher priority. The bridge having the lowest priority will be elected as root bridge.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>GroupForwardMask=</varname></term> + <listitem> + <para>A 16-bit bitmask represented as an integer which allows forwarding of link + local frames with 802.1D reserved addresses (01:80:C2:00:00:0X). A logical AND + is performed between the specified bitmask and the exponentiation of 2^X, the + lower nibble of the last octet of the MAC address. For example, a value of 8 + would allow forwarding of frames addressed to 01:80:C2:00:00:03 (802.1X PAE).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>DefaultPVID=</varname></term> + <listitem> + <para>This specifies the default port VLAN ID of a newly attached bridge port. + Set this to an integer in the range 1–4094 or <literal>none</literal> to disable the PVID.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastQuerier=</varname></term> + <listitem> + <para>Takes a boolean. This setting controls the IFLA_BR_MCAST_QUERIER option in the kernel. + If enabled, the kernel will send general ICMP queries from a zero source address. + This feature should allow faster convergence on startup, but it causes some + multicast-aware switches to misbehave and disrupt forwarding of multicast packets. + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MulticastSnooping=</varname></term> + <listitem> + <para>Takes a boolean. This setting controls the IFLA_BR_MCAST_SNOOPING option in the kernel. + If enabled, IGMP snooping monitors the Internet Group Management Protocol (IGMP) traffic + between hosts and multicast routers. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>VLANFiltering=</varname></term> + <listitem> + <para>Takes a boolean. This setting controls the IFLA_BR_VLAN_FILTERING option in the kernel. + If enabled, the bridge will be started in VLAN-filtering mode. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>STP=</varname></term> + <listitem> + <para>Takes a boolean. This enables the bridge's Spanning Tree Protocol (STP). + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[VLAN] Section Options</title> + + <para>The <literal>[VLAN]</literal> section only applies for + netdevs of kind <literal>vlan</literal>, and accepts the + following key:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Id=</varname></term> + <listitem> + <para>The VLAN ID to use. An integer in the range 0–4094. + This option is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>GVRP=</varname></term> + <listitem> + <para>Takes a boolean. The Generic VLAN Registration Protocol (GVRP) is a protocol that + allows automatic learning of VLANs on a network. + When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MVRP=</varname></term> + <listitem> + <para>Takes a boolean. Multiple VLAN Registration Protocol (MVRP) formerly known as GARP VLAN + Registration Protocol (GVRP) is a standards-based Layer 2 network protocol, + for automatic configuration of VLAN information on switches. It was defined + in the 802.1ak amendment to 802.1Q-2005. When unset, the kernel's default will be used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>LooseBinding=</varname></term> + <listitem> + <para>Takes a boolean. The VLAN loose binding mode, in which only the operational state is passed + from the parent to the associated VLANs, but the VLAN device state is not changed. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>ReorderHeader=</varname></term> + <listitem> + <para>Takes a boolean. The VLAN reorder header is set VLAN interfaces behave like physical interfaces. + When unset, the kernel's default will be used.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[MACVLAN] Section Options</title> + + <para>The <literal>[MACVLAN]</literal> 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>, and + <literal>passthru</literal>. + </para> + </listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>[MACVTAP] Section Options</title> + + <para>The <literal>[MACVTAP]</literal> section applies for + netdevs of kind <literal>macvtap</literal> and accepts the + same key as <literal>[MACVLAN]</literal>.</para> + + </refsect1> + + <refsect1> + <title>[IPVLAN] Section Options</title> + + <para>The <literal>[IPVLAN]</literal> 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>[VXLAN] Section Options</title> + <para>The <literal>[VXLAN]</literal> section only applies for + netdevs of kind <literal>vxlan</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Id=</varname></term> + <listitem> + <para>The VXLAN ID to use.</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>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. N is a number in the range 1–255. 0 + is a special value meaning that packets inherit the 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>DestinationPort=</varname></term> + <listitem> + <para>Configures the default destination UDP port on a per-device basis. + If destination port is not specified then Linux kernel default will be used. + Set destination port 4789 to get the IANA assigned value. If not set or if the + destination port is assigned the empty string the default port of 4789 is used.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PortRange=</varname></term> + <listitem> + <para>Configures VXLAN port range. VXLAN bases source + UDP port based on flow to help the receiver to be able + to load balance based on outer header flow. It + restricts the port range to the normal UDP local + ports, and allows overriding via configuration.</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> + </variablelist> + </refsect1> + <refsect1> + <title>[GENEVE] Section Options</title> + <para>The <literal>[GENEVE]</literal> section only applies for + netdevs of kind <literal>geneve</literal>, and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Id=</varname></term> + <listitem> + <para>Specifies the Virtual Network Identifier (VNI) to use. Ranges [0-16777215].</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. Ranges [1-255].</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>TTL=</varname></term> + <listitem> + <para>Specifies the TTL value to use in outgoing packets. Ranges [1-255].</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>UDPChecksum=</varname></term> + <listitem> + <para>Takes a boolean. When true, specifies if 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> + </variablelist> + </refsect1> + <refsect1> + <title>[Tunnel] Section Options</title> + + <para>The <literal>[Tunnel]</literal> 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>, and + <literal>ip6tnl</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.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Remote=</varname></term> + <listitem> + <para>The remote endpoint of the tunnel.</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: 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 + 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 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 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 true tunnel does not require .network file. Created as "tunnel@NONE". + Defaults to <literal>false</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. 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 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 <literal>[FooOverUDP]</literal></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 ERSPAN tunnel. + 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 <literal>[FooOverUDP]</literal> section only applies for + netdevs of kind <literal>fou</literal> and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Protocol=</varname></term> + <listitem> + <para>The <varname>Protocol=</varname> specifies the protocol number of the + packets arriving at the UDP port. This field is mandatory and is not set by default. Valid range is 1-255.</para> + </listitem> + </varlistentry> + <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 IP encapsulation packets will arrive. Please take note that the packets + will arrive with the encapsulation will be removed. Then they will be manually fed back into the network stack, and sent ahead + for delivery to the real destination. This option is mandatory.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + <refsect1> + <title>[Peer] Section Options</title> + + <para>The <literal>[Peer]</literal> section only applies for + netdevs of kind <literal>veth</literal> and accepts the + following keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Name=</varname></term> + <listitem> + <para>The interface name used when creating the netdev. + This option is compulsory.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>The peer MACAddress, if not set, it is generated in + the same way as the MAC address of the main + interface.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + <refsect1> + <title>[VXCAN] Section Options</title> + <para>The <literal>[VXCAN]</literal> section only applies for + netdevs of kind <literal>vxcan</literal> and accepts the + following key:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Peer=</varname></term> + <listitem> + <para>The peer interface name used when creating the netdev. + This option is compulsory.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + <refsect1> + <title>[Tun] Section Options</title> + + <para>The <literal>[Tun]</literal> section only applies for + netdevs of kind <literal>tun</literal>, and accepts the following + keys:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>OneQueue=</varname></term> + <listitem><para>Takes a boolean. Configures whether + all packets are queued at the device (enabled), or a fixed + number of packets are queued at the device and the rest at the + <literal>qdisc</literal>. Defaults to + <literal>no</literal>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>MultiQueue=</varname></term> + <listitem><para>Takes a boolean. Configures whether + to use multiple file descriptors (queues) to parallelize + 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 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 <literal>[Tap]</literal> section only applies for + netdevs of kind <literal>tap</literal>, and accepts the same keys + as the <literal>[Tun]</literal> section.</para> + </refsect1> + + <refsect1> + <title>[WireGuard] Section Options</title> + + <para>The <literal>[WireGuard]</literal> 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 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>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>FwMark=</varname></term> + <listitem> + <para>Sets a firewall mark on outgoing WireGuard packets from this interface.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[WireGuardPeer] Section Options</title> + + <para>The <literal>[WireGuardPeer]</literal> 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-networkd</literal> + with a <literal>0640</literal> file mode.</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. The catch-all + 0.0.0.0/0 may be specified for matching all IPv4 addresses, and + ::/0 may be specified for matching all IPv6 addresses. </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Endpoint=</varname></term> + <listitem> + <para>Sets an endpoint IP address or hostname, followed by a colon, and then + a port number. This endpoint will be updated automatically once to + the most recent source IP address and port of correctly + authenticated packets from the peer at configuration time.</para> + </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 <literal>[Bond]</literal> 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. Ranges [1-65535].</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AdUserPortKey=</varname></term> + <listitem> + <para>Specifies the 802.3ad user defined portion of the port key. Ranges [0-1023].</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>AdActorSystem=</varname></term> + <listitem> + <para>Specifies the 802.3ad system mac address. This can not be either NULL or Multicast.</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 in milliseconds. + A value of 0 disables ARP monitoring. The default value is 0. + </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>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-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> + </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..ee464ff --- /dev/null +++ b/man/systemd.network.xml @@ -0,0 +1,2137 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="systemd.network" conditional='ENABLE_NETWORKD'> + + <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>Network setup is performed by + <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </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 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 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 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> + + <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 <literal>[Match]</literal> + section, which determines if a given network file may be applied + to a given device; and a <literal>[Network]</literal> 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 device if each of the + entries in the <literal>[Match]</literal> section matches, or if + the section is empty. The following keys are accepted:</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>A whitespace-separated list of hardware addresses. Use full colon-, hyphen- or dot-delimited hexadecimal. See the example below. + This option may appear more than one, in which case the lists are merged. If the empty string is assigned to this option, the list + 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> + <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 <literal>ID_PATH</literal>. If the list is + prefixed with a "!", the test is inverted; i.e. it is + true when <literal>ID_PATH</literal> does not match any + item in the list.</para> + </listitem> + </varlistentry> + <varlistentry> + <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 <literal>DRIVER</literal> + of its parent device, or if that is not set the driver + as exposed by <literal>ethtool -i</literal> of the + device itself. If the list is prefixed with a "!", the + test is inverted.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Type=</varname></term> + <listitem> + <para>A whitespace-separated list of shell-style globs + matching the device type, as exposed by the udev property + <literal>DEVTYPE</literal>. If the list is prefixed with + a "!", the test is inverted.</para> + </listitem> + </varlistentry> + <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>. If the list is prefixed + with a "!", the test is inverted.</para> + </listitem> + </varlistentry> + <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. + </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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>KernelCommandLine=</varname></term> + <listitem> + <para>Checks whether a specific kernel command line option is + set (or if prefixed with the exclamation mark unset). See + <literal>ConditionKernelCommandLine=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for details. + </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 (or if prefixed with the exclamation mark does not match it). See + <literal>ConditionKernelVersion=</literal> in + <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for + details. + </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. + </para> + </listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>[Link] Section Options</title> + + <para> The <literal>[Link]</literal> 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>RequiredForOnline=</varname></term> + <listitem> + <para>Takes a boolean. When <literal>yes</literal>, the network is deemed + required when determining whether the system is online when running + <literal>systemd-networkd-wait-online</literal>. + When <literal>no</literal>, the network is ignored when checking for + online state. 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 <literal>systemd-networkd-wait-online</literal> + if <literal>RequiredForOnline=no</literal>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Network] Section Options</title> + + <para>The <literal>[Network]</literal> 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 <literal>[DHCP]</literal> section 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 start. Defaults + to <literal>no</literal>. Further settings for the DHCP + server may be set in the <literal>[DHCPServer]</literal> + 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>, or <literal>ipv6</literal>. Defaults to + <literal>ipv6</literal>.</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>IPv6Token=</varname></term> + <listitem> + <para>An IPv6 address with the top 64 bits unset. When set, indicates the + 64-bit interface part of SLAAC IPv6 addresses for this link. Note that + the token is only ever used for SLAAC, and not for DHCPv6 addresses, even + in the case DHCP is requested by router advertisement. By default, the + token is autogenerated.</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 false or + <literal>opportunistic</literal>. When set to <literal>opportunistic</literal>, enables + <ulink + url="https://tools.ietf.org/html/rfc7858">DNS-over-TLS</ulink> + support on the link. This option defines a + per-interface setting for + <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 host name, 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 0.0.0.0 (for IPv4) or + [::] (for IPv6), a new address range of the requested size + is automatically allocated from a system-wide pool of + unused ranges. 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 fc00::/7 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. 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 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 host names (host names containing no dots) to + become fully qualified domain names (FQDNs). If a single-label host name 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 host names + 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. 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, independently of the local forwarding state. + If unset, the kernel's default is used, and RAs are accepted only when local forwarding + is disabled for that interface. When RAs are accepted, they may trigger the start of the DHCPv6 client if + the relevant flags are set in the RA data, or if no routers are found on the link.</para> + + <para>Further settings for the IPv6 RA support may be configured in the + <literal>[IPv6AcceptRA]</literal> 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> + </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>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>IPv6PrefixDelegation=</varname></term> + <listitem><para>Whether to enable or disable Router Advertisement sending on a link. + Allowed values are <literal>static</literal> which distributes prefixes as defined in + the <literal>[IPv6PrefixDelegation]</literal> and any <literal>[IPv6Prefix]</literal> + sections, <literal>dhcpv6</literal> which requests prefixes using a DHCPv6 client + configured for another link and any values configured in the + <literal>[IPv6PrefixDelegation]</literal> section while ignoring all static prefix + configuration sections, <literal>yes</literal> which uses both static configuration + and DHCPv6, and <literal>false</literal> which turns off IPv6 prefix delegation + altogether. Defaults to <literal>false</literal>. See the + <literal>[IPv6PrefixDelegation]</literal> and the <literal>[IPv6Prefix]</literal> + sections for more configuration options. + </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>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. + </para> + </listitem> + </varlistentry> + </variablelist> + + </refsect1> + + <refsect1> + <title>[Address] Section Options</title> + + <para>An <literal>[Address]</literal> section accepts the + following keys. Specify several <literal>[Address]</literal> + sections to configure several addresses.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Address=</varname></term> + <listitem> + <para>As in the <literal>[Network]</literal> section. This + key is mandatory.</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 <literal>Address</literal> + 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 <literal>Address</literal> + 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>, + <literal>link</literal> or <literal>host</literal> or an unsigned integer ranges 0 to 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 a boolean. Do not perform Duplicate Address Detection + <ulink url="https://tools.ietf.org/html/rfc4862">RFC 4862</ulink> when adding this address. + Supported only on IPv6. Defaults to false.</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 to use privacy + extensions in a manually configured network, just like if stateless auto-configuration + was active. Defaults to false. </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>PrefixRoute=</varname></term> + <listitem> + <para>Takes a boolean. When adding or modifying an IPv6 address, the userspace + application needs a way to suppress adding a prefix route. This is for example relevant + together with IFA_F_MANAGERTEMPADDR, where userspace creates autoconf generated addresses, + but depending on on-link, no route for the prefix should be added. Defaults to false.</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 <literal>[Neighbor]</literal> 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 <literal>[Neighbor]</literal> 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>MACAddress=</varname></term> + <listitem> + <para>The hardware address of the neighbor.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[IPv6AddressLabel] Section Options</title> + + <para>An <literal>[IPv6AddressLabel]</literal> section accepts the + following keys. Specify several <literal>[IPv6AddressLabel]</literal> + 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) ranges 0 to 4294967294. + 0xffffffff is reserved. This key 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 <literal>[RoutingPolicyRule]</literal> section accepts the + following keys. Specify several <literal>[RoutingPolicyRule]</literal> + sections to configure several rules.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>TypeOfService=</varname></term> + <listitem> + <para>Specifies the type of service to match a number between 0 to 255.</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).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Table=</varname></term> + <listitem> + <para>Specifies the routing table identifier to lookup if the rule + selector matches. The table identifier for a route (a number between 1 and 4294967295).</para> + </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 wheather the rule to be inverted. Defaults to false.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>[Route] Section Options</title> + <para>The <literal>[Route]</literal> section accepts the + following keys. Specify several <literal>[Route]</literal> + sections to configure several routes.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>Gateway=</varname></term> + <listitem> + <para>As in the <literal>[Network]</literal> section.</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">RFC4191</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 route, which can be <literal>global</literal>, + <literal>link</literal> or <literal>host</literal>. Defaults to + <literal>global</literal>.</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=<replaceable>num</replaceable></varname></term> + <listitem> + <para>The table identifier for the route (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>Protocol=</varname></term> + <listitem> + <para>The protocol identifier for the route. Takes a number between 0 and 255 or the special values + <literal>kernel</literal>, <literal>boot</literal> and <literal>static</literal>. Defaults to + <literal>static</literal>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><varname>Type=</varname></term> + <listitem> + <para>Specifies the type for the route. If <literal>unicast</literal>, a regular route is defined, i.e. a + 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 data bytes + will be sent during the initial burst of data. Takes a size in bytes between 1 and 4294967295 (2^32 - 1). The usual + suffixes K, M, G are supported and are understood to the base of 1024. When unset, the kernel's default will be used. + </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 initally be buffered at one time + on a connection. The sending host can send only that amount of data before waiting for an acknowledgment and window update + from the receiving host. Takes a size in bytes between 1 and 4294967295 (2^32 - 1). The usual suffixes K, M, G are supported + and are understood to the base of 1024. When unset, the kernel's default will be used. + </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>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> + </variablelist> + </refsect1> + + <refsect1> + <title>[DHCP] Section Options</title> + <para>The <literal>[DHCP]</literal> section configures the + DHCPv4 and DHCP6 client, if it is enabled with the + <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>UseNTP=</varname></term> + <listitem> + <para>When true (the default), the NTP servers received + from the DHCP server will be used by systemd-timesyncd + and take precedence over any statically configured ones.</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>SendHostname=</varname>, + <varname>UseMTU=</varname>, <varname>VendorClassIdentifier=</varname>, + <varname>UseTimezone=</varname>.</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>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 host names, 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>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>CriticalConnection=</varname></term> + <listitem> + <para>When true, the connection will never be torn down + even if the DHCP lease expires. This is contrary to the + DHCP specification, but may be the best choice if, say, + the root filesystem relies on this connection. Defaults to + false.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>ClientIdentifier=</varname></term> + <listitem> + <para>The DHCPv4 client identifier to use. Takes one of <literal>mac</literal>, <literal>duid</literal> or <literal>duid-only</literal>. + 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>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.</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 unless this parameter is specified. + </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>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-method 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>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> + + </variablelist> + </refsect1> + + <refsect1> + <title>[IPv6AcceptRA] Section Options</title> + <para>The <literal>[IPv6AcceptRA]</literal> 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 host names, 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> + </variablelist> + </refsect1> + + <refsect1> + <title>[DHCPServer] Section Options</title> + <para>The <literal>[DHCPServer]</literal> 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>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 or NTP server information at a + later point. DNS server propagation does not take + <filename>/etc/resolv.conf</filename> into account. 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> + + <listitem><para>Similar to the <varname>EmitDNS=</varname> and + <varname>DNS=</varname> settings described above, these + settings configure whether and what NTP server information + 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> + + </variablelist> + </refsect1> + + <refsect1> + <title>[IPv6PrefixDelegation] Section Options</title> + <para>The <literal>[IPv6PrefixDelegation]</literal> section contains + settings for sending IPv6 Router Advertisements and whether to act as + a router, if enabled via the <varname>IPv6PrefixDelegation=</varname> + option described above. IPv6 network prefixes are defined with one or + more <literal>[IPv6Prefix]</literal> 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. If set, + this host also announces itself in Router Advertisements as an IPv6 + router for the network link. When unset, the host is not acting as a router.</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 distributed via Router Advertisement + messages when <varname>EmitDNS=</varname> is true. If <varname>DNS= + </varname> is empty, DNS servers are read from the + <literal>[Network]</literal> section. If the + <literal>[Network]</literal> 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 + <literal>[Network]</literal> section. If the <literal>[Network]</literal> + 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 <literal>[IPv6Prefix]</literal> 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 + <literal>[IPv6Prefix]</literal> 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> + + </variablelist> + </refsect1> + + <refsect1> + <title>[Bridge] Section Options</title> + <para>The <literal>[Bridge]</literal> 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>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>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, and 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>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 <literal>[BridgeFDB]</literal> section manages the + forwarding database table of a port and accepts the following + keys. Specify several <literal>[BridgeFDB]</literal> sections to + configure several static MAC table entries.</para> + + <variablelist class='network-directives'> + <varlistentry> + <term><varname>MACAddress=</varname></term> + <listitem> + <para>As in the <literal>[Network]</literal> section. This + key is mandatory.</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> + </variablelist> + </refsect1> + + <refsect1> + <title>[CAN] Section Options</title> + <para>The <literal>[CAN]</literal> 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.</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>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> + </variablelist> + </refsect1> + + <refsect1> + <title>[BridgeVLAN] Section Options</title> + <para>The <literal>[BridgeVLAN]</literal> section manages the VLAN ID configuration of a bridge port and accepts + the following keys. Specify several <literal>[BridgeVLAN]</literal> sections to configure several VLAN entries. + The <varname>VLANFiltering=</varname> option has to be enabled, see <literal>[Bridge]</literal> 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>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> + </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..7924641 --- /dev/null +++ b/man/systemd.nspawn.xml @@ -0,0 +1,568 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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>) encodes additional runtime + information about a local container, and is searched, read and + used by + <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> + when starting a container. 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 following the <ulink + url="http://standards.freedesktop.org/desktop-entry-spec/latest/">XDG + Desktop Entry Specification</ulink>, which in turn are inspired by + Microsoft Windows <filename>.ini</filename> files.</para> + + <para>Boolean arguments used in these settings 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>Empty lines and lines starting with # or ; are + ignored. This may be used for commenting. 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.</para> + + </refsect1> + + <refsect1> + <title><filename>.nspawn</filename> File Discovery</title> + + <para>Files are searched 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 in + <filename>/etc/systemd/nspawn/</filename> and + <filename>/run/systemd/nspawn/</filename>. If found in these + directories, its settings are read and all of them take full effect + (but are possibly overridden by corresponding command line + arguments). If not found, the file will then be searched 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 <literal>[Exec]</literal> + 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 the default if the + <filename>systemd-nspawn@.service</filename> template unit file is used.</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 space-separated list of + arguments. This is either a command line, beginning with the + binary name to execute, or – if <varname>Boot=</varname> is + enabled – the list of arguments to pass to the init + process. This setting corresponds to the command line + parameters passed on the <command>systemd-nspawn</command> + command line.</para></listitem> + </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.</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 <literal>[Files]</literal> + 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>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 <literal>[Network]</literal> + 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>. 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..13fdfc2 --- /dev/null +++ b/man/systemd.offline-updates.xml @@ -0,0 +1,166 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 noindex="true">/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 noindex="true">/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 upgrade scripts should exit only after the update is finished. It is expected + that the service which performs the upgrade 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 noindex='true'>.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 noindex='true'>/usr/lib/systemd/system-update.target.wants/foobar.service</filename> + → <filename noindex='true'>../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 + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/logind">logind dbus API</ulink> + for details.</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> + 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 noindex='true'>/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..e513fe6 --- /dev/null +++ b/man/systemd.path.xml @@ -0,0 +1,195 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </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..cf807bd --- /dev/null +++ b/man/systemd.preset.xml @@ -0,0 +1,174 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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 # or + ; are ignored.</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>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..a4d793c --- /dev/null +++ b/man/systemd.resource-control.xml @@ -0,0 +1,929 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="systemd.resource-control"> + <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/Documentation/cgroup-v2.txt">cgroup-v2.txt</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><option>CPU</option></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><option>Memory</option></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><option>IO</option></term> + <listitem> + <para><varname>IO</varname> prefixed settings are a superset of and replace <varname>BlockIO</varname> + prefixed ones. On unified hierarchy, IO resource control also applies to buffered writes.</para> + </listitem> + </varlistentry> + + </variablelist> + </para> + + <para>To ease the transition, there is best-effort translation between the two versions of settings. 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/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</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 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/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink> and <ulink + url="https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt">sched-design-CFS.txt</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/Documentation/cgroup-v2.txt">cgroup-v2.txt</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>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></term> + + <listitem> + <para>Specify the memory usage protection of the executed processes in this unit. If the memory usages of + this unit and all its ancestors are below their minimum boundaries, this unit's memory won't be reclaimed.</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. This controls the <literal>memory.min</literal> control group attribute. For details about this + control group attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used and disables + <varname>MemoryLimit=</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryLow=<replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Specify the best-effort memory usage protection of the executed processes in this unit. If the memory + usages of this unit and all its ancestors are below their low boundaries, this unit's memory won't be + reclaimed as long as memory can be reclaimed from unprotected units.</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. This controls the <literal>memory.low</literal> control group attribute. For details about this + control group attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.</para> + + <para>This setting is supported only if the unified control group hierarchy is used and disables + <varname>MemoryLimit=</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>MemoryHigh=<replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Specify the high 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 limit 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/Documentation/cgroup-v2.txt">cgroup-v2.txt</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/Documentation/cgroup-v2.txt">cgroup-v2.txt</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/Documentation/cgroup-v2.txt">cgroup-v2.txt</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/Documentation/cgroup-v1/pids.txt">pids.txt</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/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>. The available I/O + bandwidth is split up among all units within one slice relative to their block I/O weight.</para> + + <para>While <varname>StartupIOWeight=</varname> only applies + to the startup phase of the system, + <varname>IOWeight=</varname> applies to the later runtime of + the system, and if the former is not set also to the startup + phase. This allows prioritizing specific services at boot-up + differently than during runtime.</para> + + <para>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/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.</para> + + <para>This setting replaces <varname>BlockIODeviceWeight=</varname> and disables settings prefixed with + <varname>BlockIO</varname> or <varname>StartupBlockIO</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOReadBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> + <term><varname>IOWriteBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified + control group hierarchy is used on the system. This limit is not work-conserving and the executed processes + are not allowed to use more even if the device has idle capacity. Takes a space-separated pair of a file + path and a bandwidth value (in bytes per second) to specify the device specific bandwidth. The file path may + be a path to a block device node, or as any other file in which case the backing block device of the file + system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the <literal>io.max</literal> control + group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For details + about this control group attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>. + </para> + + <para>These settings replace <varname>BlockIOReadBandwidth=</varname> and + <varname>BlockIOWriteBandwidth=</varname> and disable settings prefixed with <varname>BlockIO</varname> or + <varname>StartupBlockIO</varname>.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>IOReadIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term> + <term><varname>IOWriteIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term> + + <listitem> + <para>Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the + unified control group hierarchy is used on the system. This limit is not work-conserving and the executed + processes are not allowed to use more even if the device has idle capacity. Takes a space-separated pair of + a file path and an IOPS value to specify the device specific IOPS. The file path may be a path to a block + device node, or as any other file in which case the backing block device of the file system of the file is + used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS, MegaIOPS, + GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This controls the <literal>io.max</literal> control + group attributes. Use this option multiple times to set IOPS limits for multiple devices. For details about + this control group attribute, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>. + </para> + + <para>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> + </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/Documentation/cgroup-v2.txt">cgroup-v2.txt</ulink>.</para> + + <para>Implies <literal>IOAccounting=yes</literal>.</para> + + <para>These settings are supported only if the unified control group hierarchy is used.</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 address range network traffic filtering for packets sent and received over AF_INET and AF_INET6 + sockets. Both directives take a space separated list of IPv4 or IPv6 addresses, each optionally suffixed + with an address prefix length (separated by a <literal>/</literal> character). If the latter is omitted, the + address is considered a host address, i.e. the prefix covers the whole address (32 for IPv4, 128 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 all access lists are + empty. When configured the lists are enforced as follows:</para> + + <itemizedlist> + <listitem><para>Access will be granted in case its destination/source address matches any entry in the + <varname>IPAddressAllow=</varname> setting.</para></listitem> + + <listitem><para>Otherwise, access will be denied in case its destination/source address matches any entry + in the <varname>IPAddressDeny=</varname> setting.</para></listitem> + + <listitem><para>Otherwise, access will be granted.</para></listitem> + </itemizedlist> + + <para>In order to implement a whitelisting 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, however it often makes 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>DeviceAllow=</varname></term> + + <listitem> + <para>Control access to specific device nodes by the + executed processes. Takes two space-separated strings: a + device node specifier followed by a combination of + <constant>r</constant>, <constant>w</constant>, + <constant>m</constant> to control + <emphasis>r</emphasis>eading, <emphasis>w</emphasis>riting, + or creation of the specific device node(s) by the unit + (<emphasis>m</emphasis>knod), respectively. This controls + the <literal>devices.allow</literal> and + <literal>devices.deny</literal> control group + attributes. For details about these control group + attributes, see <ulink + url="https://www.kernel.org/doc/Documentation/cgroup-v1/devices.txt">devices.txt</ulink>.</para> + + <para>The device node specifier is either a path to a device + node in the file system, starting with + <filename>/dev/</filename>, or a string starting with either + <literal>char-</literal> or <literal>block-</literal> + followed by a device group name, as listed in + <filename>/proc/devices</filename>. The latter is useful to + whitelist all current and future devices belonging to a + specific device group at once. The device group is matched + according to filename globbing rules, you may hence use the + <literal>*</literal> and <literal>?</literal> + wildcards. Examples: <filename>/dev/sda5</filename> is a + path to a device node, referring to an ATA or SCSI block + device. <literal>char-pts</literal> and + <literal>char-alsa</literal> are specifiers for all pseudo + TTYs and all ALSA sound devices, + respectively. <literal>char-cpu/*</literal> is a specifier + matching all CPU related device groups.</para> + </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> + + <para>The following controller names may be specified: <option>cpu</option>, <option>cpuacct</option>, + <option>io</option>, <option>blkio</option>, <option>memory</option>, <option>devices</option>, + <option>pids</option>. 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> + + <para>Valid controllers are <option>cpu</option>, <option>cpuacct</option>, <option>io</option>, + <option>blkio</option>, <option>memory</option>, <option>devices</option>, and <option>pids</option>.</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/Documentation/scheduler/sched-design-CFS.txt">sched-design-CFS.txt</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/Documentation/cgroup-v1/memory.txt">memory.txt</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/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>. + The available I/O bandwidth is split up among all units within one slice relative to their block I/O + weight.</para> + + <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/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</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/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</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>, + The documentation for control groups and specific controllers in the Linux kernel: + <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink>, + <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/cpuacct.txt">cpuacct.txt</ulink>, + <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt">memory.txt</ulink>, + <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/blkio-controller.txt">blkio-controller.txt</ulink>. + <ulink url="https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt">sched-bwc.txt</ulink>. + </para> + </refsect1> +</refentry> diff --git a/man/systemd.scope.xml b/man/systemd.scope.xml new file mode 100644 index 0000000..18560fb --- /dev/null +++ b/man/systemd.scope.xml @@ -0,0 +1,95 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </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>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..f0f9aee --- /dev/null +++ b/man/systemd.service.xml @@ -0,0 +1,1428 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + <literal>[Unit]</literal> and <literal>[Install]</literal> + sections. The service specific configuration options are + configured in the <literal>[Service]</literal> 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> + </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 <literal>[Service]</literal> + 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 <literal>[Service]</literal> 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 started after the main process exits. It will then start follow-up + units. <varname>RemainAfterExit=</varname> is particularly useful for this type of + service. <varname>Type=</varname><option>oneshot</option> is the implied default if neither + <varname>Type=</varname> nor <varname>ExecStart=</varname> are specified.</para></listitem> + + <listitem><para>Behavior of <option>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.</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>. Note that currently <varname>Type=</varname><option>notify</option> will not work if + used in combination with <varname>PrivateNetwork=</varname><option>yes</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 bus name that this service is + reachable as. This option is mandatory for services where + <varname>Type=</varname> is set to + <option>dbus</option>.</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> 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>, 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> + </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>/bin/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.</para> + </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> + 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 queuing some form of termination signal for 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> 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, 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. When the commands specified with this option are executed it should be assumed that the service is + still fully up and is able to react correctly to all commands. 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></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. 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 exended 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 + <constant>ExecStop=</constant> command. If any of them times out, subsequent <constant>ExecStop=</constant> commands + are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <constant>ExecStop=</constant> + commands are specified, the service gets the <constant>SIGTERM</constant> immediately. 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 exended 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>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>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 exended 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 code 0 and the signals <constant>SIGHUP</constant>, + <constant>SIGINT</constant>, <constant>SIGTERM</constant>, and + <constant>SIGPIPE</constant>. Exit status definitions can + either be numeric exit codes or termination signal names, + separated by spaces. For example: + + <programlisting>SuccessExitStatus=1 2 8 SIGKILL</programlisting> + + ensures that exit codes 1, 2, 8 and + the termination signal <constant>SIGKILL</constant> are + considered clean service terminations. + </para> + + <para>This option may appear more than once, in which case the + list of successful exit statuses is merged. If the empty + string is assigned to this option, the list is reset, all + prior assignments of this option will have no + effect.</para></listitem> + </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></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></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. If the empty string is + assigned to this option, the list of sockets is reset, and all + prior uses of this setting will have no + effect.</para></listitem> + </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. 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> + + </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 replaced by the + value of the environment variable including all whitespace it + contains, resulting in 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 determinted 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>/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. They will be executed + in order until either they are all successful or one of them + fails.</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 <literal>[Install]</literal> 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> + </para> + </refsect1> + +</refentry> diff --git a/man/systemd.slice.xml b/man/systemd.slice.xml new file mode 100644 index 0000000..43e7c6a --- /dev/null +++ b/man/systemd.slice.xml @@ -0,0 +1,117 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>1</manvolnum></citerefentry> + are found in <filename>machine.slice</filename>, and user sessions + handled by + <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>1</manvolnum></citerefentry> + in <filename>user.slice</filename>. See + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</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..7547071 --- /dev/null +++ b/man/systemd.socket.xml @@ -0,0 +1,875 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 file, a matching service file must exist, + describing the service to start on incoming traffic on the socket + (see + <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> + for more information about .service files). The name of the + .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 file + <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) or via the 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 AF_UNIX + 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 + v.w.x.y:z, it is read as IPv4 specifier for listening on an + address v.w.x.y on a port z.</para> + + <para>If the address string is a string in the format [x]:y, + it is read as IPv6 address x on a port y. Note that this might + 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:x:y</literal>, it is read as CID <literal>x</literal> on + a port <literal>y</literal> 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 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. This expects a valid message queue name (i.e. beginning + with /). 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 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>. Specifies a socket protocol + (<constant>IPPROTO_UDPLITE</constant>) UDP-Lite + (<constant>IPPROTO_SCTP</constant>) SCTP socket 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 + SO_BINDTODEVICE 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 + (<citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry> + is created. 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 AF_UNIX 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 true, a service + instance is spawned for each incoming connection and only the + connection socket is passed to it. If false, 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>false</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 SOCK_RAW, 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>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 + SO_KEEPALIVE 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 SO_KEEPALIVE + has been set on this socket. This controls + the TCP_KEEPINTVL 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 SO_PRIORITY 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 SO_RCVBUF and SO_SNDBUF 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 IP_TOS 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 IP_TTL/IPV6_UNICAST_HOPS 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 SO_MARK 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 SO_REUSEPORT 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>true</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 IP_FREEBIND 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 + IP_TRANSPARENT 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 + SO_BROADCAST 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 + SO_PASSCRED 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 + SO_PASSSEC 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>TCPCongestion=</varname></term> + <listitem><para>Takes a string value. Controls the TCP + congestion algorithm used by this socket. Should be one of + "westwood", "veno", "cubic", "lp" 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 AF_UNIX 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..fd5639b --- /dev/null +++ b/man/systemd.special.xml @@ -0,0 +1,1109 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>boot-complete.target</filename>, + <filename>default.target</filename>, + <filename>emergency.target</filename>, + <filename>exit.target</filename>, + <filename>final.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-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-sync.target</filename>, + <filename>timers.target</filename>, + <filename>umount.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's 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>.</para> + + <para>The default unit systemd starts at bootup can be + overridden with the <varname>systemd.unit=</varname> kernel + command line option.</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 any 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 is supposed + to be used with the kernel command line option <varname>systemd.unit=</varname>; 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>Use the <literal>systemd.unit=emergency.target</literal> kernel command line + option to boot into this mode. A short alias for this kernel command line option is + <literal>emergency</literal>, for compatibility with SysV.</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> + </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 + <literal>[Install]</literal> 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-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 + <literal>[Install]</literal> 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 + <literal>[Install]</literal> 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 <literal>[Install]</literal> + 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 <literal>[Install]</literal> + 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 <literal>[Install]</literal> 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> + </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>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>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-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's service manager</title> + + <refsect2> + <title>Special User Units</title> + + <para>When systemd runs as a user instance, the following special + units are available, which have similar definitions as their + system counterparts: + <filename>exit.target</filename>, + <filename>default.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 <literal>[Unit]</literal> + 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> + </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..cf00451 --- /dev/null +++ b/man/systemd.swap.xml @@ -0,0 +1,261 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 + noindex='true'>/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> + </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 initalized.</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 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>%%</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..67cd640 --- /dev/null +++ b/man/systemd.syntax.xml @@ -0,0 +1,129 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ --> + +<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></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>. + 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 2\ +# this line is ignored +; this line is ignored too + value 2 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..10aa91a --- /dev/null +++ b/man/systemd.target.xml @@ -0,0 +1,138 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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..24df5ab --- /dev/null +++ b/man/systemd.time.xml @@ -0,0 +1,301 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + </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 (eg: with local timezone it's possible to + specify daylight saving time in winter, while it's incorrect). 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 TZ=Asia/Shanghai):</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> + </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.</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 elapse 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..d254c77 --- /dev/null +++ b/man/systemd.timer.xml @@ -0,0 +1,308 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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: <varname>OnActiveSec=</varname> defines a + timer relative to the moment the timer itself is activated. + <varname>OnBootSec=</varname> defines a timer relative to when + the machine was booted up. <varname>OnStartupSec=</varname> + defines a timer relative to when systemd was first started. + <varname>OnUnitActiveSec=</varname> defines a timer relative + to when the unit the timer is activating was last activated. + <varname>OnUnitInactiveSec=</varname> defines a timer relative + to when the unit the timer is activating was last + deactivated.</para> + + <para>Multiple directives may be combined of the same and of + different types. 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.</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 stops too.</para> + + <para>If the empty string is assigned to any of these options, + the list of timers is reset, 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.</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></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. This is + useful to stretch dispatching of similarly configured timer + events over a certain amount time, to avoid that they all fire + at the same time, possibly resulting in resource + congestion. 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, the former does the + opposite: it stretches timer events over a time range, 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 1min 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, make sure to set + <varname>RandomizedDelaySec=</varname> to a higher value, and + <varname>AccuracySec=1us</varname>.</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. This is useful to + catch up on missed runs of the service when the machine was + off. Note that this setting only has an effect on timers + configured with <varname>OnCalendar=</varname>. Defaults + to <varname>false</varname>. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>WakeSystem=</varname></term> + + <listitem><para>Takes a boolean argument. If true, an elapsing + timer will cause the system to resume from suspend, should it + be suspended and if the system supports this. Note that this + option will only make sure the system resumes on the + appropriate times, it will not take care of suspending it + again after any work that is to be done is finished. Defaults + to <varname>false</varname>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>RemainAfterElapse=</varname></term> + + <listitem><para>Takes a boolean argument. If true, an elapsed + timer will stay loaded, and its state remains queriable. If + false, an elapsed timer unit that cannot elapse anymore is + unloaded. Turning this off is particularly useful for + transient timer units that shall disappear after they first + elapse. Note that this setting has an effect on repeatedly + starting a timer unit that only elapses once: if + <varname>RemainAfterElapse=</varname> is on, it will not be + started again, and is guaranteed to elapse only once. However, + if <varname>RemainAfterElapse=</varname> is off, it might be + started again if it is already elapsed, and thus be triggered + multiple times. Defaults to + <varname>yes</varname>.</para></listitem> + </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..f21f9ea --- /dev/null +++ b/man/systemd.unit.xml @@ -0,0 +1,1866 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<refentry id="systemd.unit"> + + <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>…</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>~/.config/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>~/.local/share/systemd/user/*</filename> +<filename>…</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>5</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>Unit files can be parameterized by a single argument called the "instance name". The unit + is then constructed based on a "template file" which serves as the definition of multiple + services or other units. A template unit must have a single <literal>@</literal> at the end of + the name (right before the type suffix). The name of the full unit is formed by inserting the + instance name between <literal>@</literal> and the unit type suffix. In the unit file itself, + the instance parameter may be referred to using <literal>%i</literal> and other specifiers, see + below.</para> + + <para>Unit files 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 the + symlink <filename>/usr/lib/systemd/system/dbus-org.freedesktop.network1.service</filename>. In + addition, unit files may specify aliases through the <varname>Alias=</varname> directive in the + [Install] section; those aliases are only effective when the unit is enabled. When the unit is + enabled, symlinks will be created for those names, and removed when the unit is disabled. For + example, <filename>reboot.target</filename> specifies + <varname>Alias=ctrl-alt-del.target</varname>, so when enabled it will be invoked whenever + CTRL+ALT+DEL is pressed. Alias names may be used in commands like <command>enable</command>, + <command>disable</command>, <command>start</command>, <command>stop</command>, + <command>status</command>, …, and in unit dependency directives <varname>Wants=</varname>, + <varname>Requires=</varname>, <varname>Before=</varname>, <varname>After=</varname>, …, with the + limitation that aliases specified through <varname>Alias=</varname> are only effective when the + unit is enabled. Aliases cannot be used with the <command>preset</command> command.</para> + + <para>Along with a unit file <filename>foo.service</filename>, the directory + <filename>foo.service.wants/</filename> may exist. All unit files symlinked from such a + directory are implicitly added as dependencies of type <varname>Wants=</varname> to the unit. + This is useful to hook units into the start-up of other units, without having to modify their + unit files. For details about the semantics of <varname>Wants=</varname>, see below. The + preferred way to create symlinks in the <filename>.wants/</filename> directory of a unit file is + with the <command>enable</command> command of the + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> + tool which reads information from the [Install] section of unit files (see below). A similar + functionality exists for <varname>Requires=</varname> type dependencies as well, the directory + suffix is <filename>.requires/</filename> in this case.</para> + + <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 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> + + <!-- Note that we do not document .include here, as we consider it mostly obsolete, and want + people to use .d/ drop-ins instead. --> + + <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://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface + 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 NUL) 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 noindex='true'>/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>/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>Local configuration</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 morerows="1">Units of installed packages</entry> + </row> + <row> + <entry><filename>/usr/lib/systemd/system</filename></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>/etc/systemd/user</filename></entry> + <entry>Local configuration</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>$dir/systemd/user</filename> for each <varname noindex='true'>$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 morerows="1">Units of packages that have been installed system-wide</entry> + </row> + <row> + <entry><filename>/usr/lib/systemd/user</filename></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 ("linked") from + directories not on the unit load path. See the <command>link</command> command + for + <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. + </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 continous 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>Requires=</varname></term> + + <listitem><para>Configures requirement dependencies on other units. If this unit gets activated, the units + listed here 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. This option may be specified more than once or multiple space-separated units may be + specified in one option in which case requirement dependencies for all listed names will be created. 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 a unit + <filename>foo.service</filename> requires a unit <filename>bar.service</filename> as configured with + <varname>Requires=</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. 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> + + <para>Note that dependencies of this type may also be configured outside of the unit configuration file by + adding a symlink to a <filename>.requires/</filename> directory accompanying the unit file. For details, see + above.</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>Wants=</varname></term> + + <listitem><para>A weaker version of + <varname>Requires=</varname>. 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. This is the recommended way to hook start-up of one + unit to the start-up of another unit.</para> + + <para>Note that dependencies of this type may also be + configured outside of the unit configuration file by adding + symlinks to a <filename>.wants/</filename> directory + accompanying the unit file. For details, see + above.</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. Note + that this setting is independent of and orthogonal to the + <varname>After=</varname> and <varname>Before=</varname> + ordering dependencies.</para> + + <para>If a unit A that conflicts with a 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 configure ordering + dependencies between units. If a unit <filename>foo.service</filename> contains a 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. Note that this setting is + independent of and orthogonal to the requirement dependencies as configured by <varname>Requires=</varname>, + <varname>Wants=</varname> or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both + the <varname>After=</varname> and <varname>Requires=</varname> options, in which case the unit listed will be + started before the unit that is configured with these options. This option may be specified more than once, in + which case ordering dependencies for all listed names are created. <varname>After=</varname> is the inverse of + <varname>Before=</varname>, i.e. while <varname>After=</varname> ensures that the configured unit is started + after the listed unit finished starting up, <varname>Before=</varname> ensures the opposite, that the + configured unit is fully started up before the listed unit is started. Note that 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.</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> 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> 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, busname, 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>true</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>false</option>. It is highly recommended to + leave this option enabled for the majority of common units. If + set to <option>false</option>, this option does not disable + 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 overriden + 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 setting <varname>FailureAction=</varname>/<varname>SuccessAction=</varname> settings and executes + the same actions. If <option>none</option> is set, hitting the rate limit will trigger no action besides 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>ConditionArchitecture=</varname></term> + <term><varname>ConditionVirtualization=</varname></term> + <term><varname>ConditionHost=</varname></term> + <term><varname>ConditionKernelCommandLine=</varname></term> + <term><varname>ConditionKernelVersion=</varname></term> + <term><varname>ConditionSecurity=</varname></term> + <term><varname>ConditionCapability=</varname></term> + <term><varname>ConditionACPower=</varname></term> + <term><varname>ConditionNeedsUpdate=</varname></term> + <term><varname>ConditionFirstBoot=</varname></term> + <term><varname>ConditionPathExists=</varname></term> + <term><varname>ConditionPathExistsGlob=</varname></term> + <term><varname>ConditionPathIsDirectory=</varname></term> + <term><varname>ConditionPathIsSymbolicLink=</varname></term> + <term><varname>ConditionPathIsMountPoint=</varname></term> + <term><varname>ConditionPathIsReadWrite=</varname></term> + <term><varname>ConditionDirectoryNotEmpty=</varname></term> + <term><varname>ConditionFileNotEmpty=</varname></term> + <term><varname>ConditionFileIsExecutable=</varname></term> + <term><varname>ConditionUser=</varname></term> + <term><varname>ConditionGroup=</varname></term> + <term><varname>ConditionControlGroupController=</varname></term> + + <!-- We do not document ConditionNull= + here, as it is not particularly + useful and probably just + confusing. --> + + <listitem><para>Before starting a unit, verify that the specified condition is true. If it is not true, the + starting of the unit will be (mostly silently) skipped, however all ordering dependencies of it are still + respected. A failing condition will not result in the unit being moved into the <literal>failed</literal> + state. The condition is checked at the time the queued start job is to be executed. Use condition expressions + in order to silently skip units that do not apply to the local running system, for example because the kernel + or runtime environment doesn't require their functionality. Use the various + <varname>AssertArchitecture=</varname>, <varname>AssertVirtualization=</varname>, … options for a similar + mechanism that causes the job to fail (instead of being skipped) and results in logging about the failed check + (instead of being silently processed). For details about assertion conditions see below.</para> + + <para><varname>ConditionArchitecture=</varname> may be used to + check whether the system is running on a specific + architecture. Takes one of + <varname>x86</varname>, + <varname>x86-64</varname>, + <varname>ppc</varname>, + <varname>ppc-le</varname>, + <varname>ppc64</varname>, + <varname>ppc64-le</varname>, + <varname>ia64</varname>, + <varname>parisc</varname>, + <varname>parisc64</varname>, + <varname>s390</varname>, + <varname>s390x</varname>, + <varname>sparc</varname>, + <varname>sparc64</varname>, + <varname>mips</varname>, + <varname>mips-le</varname>, + <varname>mips64</varname>, + <varname>mips64-le</varname>, + <varname>alpha</varname>, + <varname>arm</varname>, + <varname>arm-be</varname>, + <varname>arm64</varname>, + <varname>arm64-be</varname>, + <varname>sh</varname>, + <varname>sh64</varname>, + <varname>m68k</varname>, + <varname>tilegx</varname>, + <varname>cris</varname>, + <varname>arc</varname>, + <varname>arc-be</varname> to test + against a specific architecture. 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 <varname>native</varname> is mapped to the + architecture the system manager itself is compiled for. The + test may be negated by prepending an exclamation mark.</para> + + <para><varname>ConditionVirtualization=</varname> may be used + to 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 + <varname>vm</varname> and + <varname>container</varname> to test against a generic type of + virtualization solution, or one of + <varname>qemu</varname>, + <varname>kvm</varname>, + <varname>zvm</varname>, + <varname>vmware</varname>, + <varname>microsoft</varname>, + <varname>oracle</varname>, + <varname>xen</varname>, + <varname>bochs</varname>, + <varname>uml</varname>, + <varname>bhyve</varname>, + <varname>qnx</varname>, + <varname>openvz</varname>, + <varname>lxc</varname>, + <varname>lxc-libvirt</varname>, + <varname>systemd-nspawn</varname>, + <varname>docker</varname>, + <varname>rkt</varname> to test + against a specific implementation, or + <varname>private-users</varname> 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> + + <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> + + <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 <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.</para> + + <para><varname>ConditionKernelVersion=</varname> may be used to check whether the kernel version (as reported + by <command>uname -r</command>) matches a certain expression (or if prefixed with the exclamation mark does not + match it). The argument must be a single string. If the string starts with one of <literal><</literal>, + <literal><=</literal>, <literal>=</literal>, <literal>>=</literal>, <literal>></literal> 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> + + <para><varname>ConditionSecurity=</varname> may be used to check + whether the given security technology is enabled on the + system. Currently, the recognized values are + <varname>selinux</varname>, <varname>apparmor</varname>, + <varname>tomoyo</varname>, <varname>ima</varname>, + <varname>smack</varname>, <varname>audit</varname> and + <varname>uefi-secureboot</varname>. The test may be negated by + prepending an exclamation mark.</para> + + <para><varname>ConditionCapability=</varname> may be used to + 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> + + <para><varname>ConditionACPower=</varname> may be used to + 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 <varname>true</varname>, + 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 + <varname>false</varname>, 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> + + <para><varname>ConditionNeedsUpdate=</varname> takes one of + <filename>/var</filename> or <filename>/etc</filename> as + argument, possibly prefixed with a <literal>!</literal> (for + inverting 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><varname>ConditionFirstBoot=</varname> takes a boolean argument. This condition may be used to + conditionalize units on whether the system is booting up with an unpopulated <filename>/etc</filename> + directory (specifically: an <filename>/etc</filename> with no <filename>/etc/machine-id</filename>). 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>With <varname>ConditionPathExists=</varname> a file + existence condition is checked before a unit is started. 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> + + <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> + + <para><varname>ConditionPathIsDirectory=</varname> is similar + to <varname>ConditionPathExists=</varname> but verifies + whether a certain path exists and is a directory.</para> + + <para><varname>ConditionPathIsSymbolicLink=</varname> is + similar to <varname>ConditionPathExists=</varname> but + verifies whether a certain path exists and is a symbolic + link.</para> + + <para><varname>ConditionPathIsMountPoint=</varname> is similar + to <varname>ConditionPathExists=</varname> but verifies + whether a certain path exists and is a mount point.</para> + + <para><varname>ConditionPathIsReadWrite=</varname> is similar + to <varname>ConditionPathExists=</varname> but verifies + whether the underlying file system is readable and writable + (i.e. not mounted read-only).</para> + + <para><varname>ConditionDirectoryNotEmpty=</varname> is + similar to <varname>ConditionPathExists=</varname> but + verifies whether a certain path exists and is a non-empty + directory.</para> + + <para><varname>ConditionFileNotEmpty=</varname> is similar to + <varname>ConditionPathExists=</varname> but verifies whether a + certain path exists and refers to a regular file with a + non-zero size.</para> + + <para><varname>ConditionFileIsExecutable=</varname> is similar + to <varname>ConditionPathExists=</varname> but verifies + whether a certain path exists, is a regular file and marked + executable.</para> + + <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> + + <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 have a special value <literal>@system</literal>.</para> + + <para><varname>ConditionControlGroupController=</varname> takes a + cgroup controller name (eg. <option>cpu</option>), verifying that it 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 + <option>cpu</option>, <option>cpuacct</option>, <option>io</option>, + <option>blkio</option>, <option>memory</option>, + <option>devices</option>, and <option>pids</option>.</para> + + <para>If multiple conditions are specified, the unit will be + executed if all of them apply (i.e. a logical AND is applied). + Condition checks can be prefixed with a pipe symbol (|) in + which case a condition becomes a triggering condition. If at + least one triggering condition is defined for a unit, then the + unit will be executed if at least one of the triggering + conditions apply and all of the non-triggering conditions. If + you prefix an argument with the pipe symbol and an exclamation + mark, the pipe symbol must be passed first, the exclamation + second. Except for + <varname>ConditionPathIsSymbolicLink=</varname>, all path + checks follow symlinks. If any of these options is assigned + the empty string, the list of conditions is reset completely, + all previous condition settings (of any kind) will have no + effect.</para></listitem> + </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> + + <para>Note that neither assertion nor condition expressions result in unit state changes. Also note that both + are checked at the time the job is to be executed, i.e. long after depending jobs and it itself were + queued. Thus, neither condition nor assertion expressions are suitable for conditionalizing unit + dependencies.</para></listitem> + </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> + </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='2'> + <colspec colname='forward' /> + <colspec colname='reverse' /> + <colspec colname='notes' /> + <thead> + <row> + <entry>"Forward" property</entry> + <entry>"Reverse" property</entry> + <entry>Where used</entry> + </row> + </thead> + <tbody> + <row> + <entry><varname>Before=</varname></entry> + <entry><varname>After=</varname></entry> + <entry morerows='1' valign='middle'>Both are unit file options</entry> + </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>A unit file option; an option in the [Install] section</entry> + </row> + <row> + <entry><varname>Wants=</varname></entry> + <entry><varname>WantedBy=</varname></entry> + <entry>A unit file option; an option in the [Install] section</entry> + </row> + <row> + <entry><varname>PartOf=</varname></entry> + <entry><varname>ConsistsOf=</varname></entry> + <entry>A unit file option; an automatic property</entry> + </row> + <row> + <entry><varname>BindsTo=</varname></entry> + <entry><varname>BoundBy=</varname></entry> + <entry>A unit file option; an automatic property</entry> + </row> + <row> + <entry><varname>Requisite=</varname></entry> + <entry><varname>RequisiteOf=</varname></entry> + <entry>A unit file option; an automatic property</entry> + </row> + <row> + <entry><varname>Triggers=</varname></entry> + <entry><varname>TriggeredBy=</varname></entry> + <entry>Automatic properties, see notes below</entry> + </row> + <row> + <entry><varname>Conflicts=</varname></entry> + <entry><varname>ConflictedBy=</varname></entry> + <entry>A unit file option; an automatic property</entry> + </row> + <row> + <entry><varname>PropagatesReloadTo=</varname></entry> + <entry><varname>ReloadPropagatedFrom=</varname></entry> + <entry morerows='1' valign='middle'>Both are unit file options</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 reverse 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>TriggersBy=</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 <literal>[Install]</literal> 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: %n, %N, %p, %i, %j, %g, %G, %U, %u, %m, %H, %b, %v. 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> + <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> + <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> + <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>%h</literal></entry> + <entry>User home directory</entry> + <entry>This is the home directory of the user running the service manager instance. In case of the system manager this resolves to <literal>/root</literal>.</entry> + </row> + <row> + <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>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 noindex='true'>/log</filename> appended (for user managers).</entry> + </row> + <row> + <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> + <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> + <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> + <row> + <entry><literal>%T</literal></entry> + <entry>Directory for temporary files</entry> + <entry>This is either <filename>/tmp</filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to.</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>%u</literal></entry> + <entry>User name</entry> + <entry>This is the name of the user running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry> + </row> + <row> + <entry><literal>%U</literal></entry> + <entry>User UID</entry> + <entry>This is the numeric UID of the user running the service manager instance. In case of the system manager this resolves to <literal>0</literal>.</entry> + </row> + <row> + <entry><literal>%v</literal></entry> + <entry>Kernel release</entry> + <entry>Identical to <command>uname -r</command> output</entry> + </row> + <row> + <entry><literal>%V</literal></entry> + <entry>Directory for larger and persistent temporary files</entry> + <entry>This is either <filename>/var/tmp</filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to.</entry> + </row> + <row> + <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> + </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>/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..5287bda --- /dev/null +++ b/man/systemd.xml @@ -0,0 +1,1263 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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.</para> + + <para>For compatibility with SysV, if systemd is called as + <command>init</command> and a PID that 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>Options</title> + + <para>The following options are understood:</para> + + <variablelist> + <varlistentry> + <term><option>--test</option></term> + + <listitem><para>Determine startup sequence, dump it and exit. + This is an option useful for debugging only.</para></listitem> + </varlistentry> + <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 to dbus. + </para></listitem> + </varlistentry> + <varlistentry> + <term><option>--unit=</option></term> + + <listitem><para>Set default unit to activate on startup. If + not specified, defaults to + <filename>default.target</filename>.</para></listitem> + </varlistentry> + <varlistentry> + <term><option>--system</option></term> + <term><option>--user</option></term> + + <listitem><para>For <option>--system</option>, tell systemd to + run a system instance, even if the process ID is not 1, i.e. + systemd is not run as init process. <option>--user</option> + does the opposite, running a user instance even if the process + ID is 1. Normally, it should not be necessary to pass these + options, as systemd automatically detects the mode it is + started in. These options are hence of little use except for + debugging. Note that it is not supported booting and + maintaining a full system with systemd running in + <option>--system</option> mode, but PID not 1. In practice, + passing <option>--system</option> explicitly is only useful in + conjunction with <option>--test</option>.</para></listitem> + </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. This setting may also + be enabled during boot on the kernel command line via the + <varname>systemd.dump_core=</varname> option, see + below.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--crash-vt=</option><replaceable>VT</replaceable></term> + + <listitem><para>Switch to a specific virtual console (VT) on + crash. Takes a positive integer in the range 1–63, or a + boolean argument. If an integer is passed, selects which VT to + switch to. If <constant>yes</constant>, the VT kernel messages + are written to is selected. If <constant>no</constant>, no VT + switch is attempted. This switch has no effect when running as + user instance. This setting may also be enabled during boot, + on the kernel command line via the + <varname>systemd.crash_vt=</varname> option, see + <!-- FIXME: there is no crash_vt command line option? --> + below.</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. This setting may also be + enabled during boot, on the kernel command line via the + <varname>systemd.crash_shell=</varname> option, see + below.</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. This + setting may also be enabled during boot, on the kernel command + line via the <varname>systemd.crash_reboot=</varname> option, + see below.</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.</para></listitem> + </varlistentry> + <varlistentry> + <term><option>--show-status=</option></term> + + <listitem><para>Takes a boolean argument or the special value <constant>auto</constant>. If on, terse unit + status information is shown on the console during boot-up and shutdown. If off, no such status information is + shown. If set to <constant>auto</constant> behavior is similar to off, except that it is automatically switched + to on, as soon as the first unit failure or significant boot delay is encountered. This switch has no effect + when invoked as user instance. If specified, overrides both the kernel command line setting + <varname>systemd.show_status=</varname> (see below) and the configuration file option + <option>ShowStatus=</option>, see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem> + </varlistentry> + <varlistentry> + <term><option>--log-target=</option></term> + + <listitem><para>Set log target. Argument must be one of + <option>console</option>, + <option>journal</option>, + <option>kmsg</option>, + <option>journal-or-kmsg</option>, + <option>null</option>.</para></listitem> + </varlistentry> + <varlistentry> + <term><option>--log-level=</option></term> + + <listitem><para>Set log level. As + argument this accepts a numerical log + level or the well-known <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> + symbolic names (lowercase): + <option>emerg</option>, + <option>alert</option>, + <option>crit</option>, + <option>err</option>, + <option>warning</option>, + <option>notice</option>, + <option>info</option>, + <option>debug</option>.</para></listitem> + </varlistentry> + <varlistentry> + <term><option>--log-color=</option></term> + + <listitem><para>Highlight important log messages. Argument is + a boolean value. If the argument is omitted, it defaults to + <option>true</option>.</para></listitem> + </varlistentry> + <varlistentry> + <term><option>--log-location=</option></term> + + <listitem><para>Include code location in log messages. This is + mostly relevant for debugging purposes. Argument is a boolean + value. If the argument is omitted it defaults to + <option>true</option>.</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. 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>syslog</option>, + <option>syslog+console</option>, + <option>kmsg</option>, + <option>kmsg+console</option>. If the + argument is omitted + <option>--default-standard-output=</option> defaults to + <option>journal</option> and + <option>--default-standard-error=</option> to + <option>inherit</option>.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--machine-id=</option></term> + + <listitem><para>Override the machine-id set on the hard drive, + useful for network booting or for containers. May not be set + to all zeros.</para></listitem> + </varlistentry> + + <varlistentry> + <term><option>--service-watchdogs=</option></term> + + <listitem><para>Globally enable/disable all service watchdog timeouts and emergency + actions. This setting may also be specified during boot, on the kernel + command line via the <varname>systemd.service_watchdogs=</varname> + option, see below. Defaults to enabled.</para></listitem> + </varlistentry> + + <xi:include href="standard-options.xml" xpointer="help" /> + <xi:include href="standard-options.xml" xpointer="version" /> + </variablelist> + </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 some sort 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 + 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://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface + 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>Systems which invoke systemd in a container or initrd + environment should implement the + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or + <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">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-irreversible</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-irreversible</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-irreversible</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-irreversible</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-irreversible</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-irreversible</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_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_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_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_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>$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> + + <listitem><para>Controls where systemd looks for unit + files.</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> + + <varlistentry> + <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> + + <varlistentry> + <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> + + <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 system instance systemd parses a number of + 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>:</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 (VT) when it + crashes. Defaults to disabled, meaning that no such switch is attempted. If + set to enabled, the VT the kernel messages are written to is selected. + </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 constant + <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. + <constant>auto</constant> behaves like <option>false</option> until a unit + fails or 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>auto</constant>. If specified overrides the system + manager configuration file option <option>ShowStatus=</option>, see + <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. + However, the process command line option <option>--show-status=</option> + takes precedence over both this kernel command line option and the + configuration file option.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>systemd.log_target=</varname></term> + <term><varname>systemd.log_level=</varname></term> + <term><varname>systemd.log_location=</varname></term> + <term><varname>systemd.log_color</varname></term> + + <listitem><para>Controls log output, with the same effect as the + <varname>$SYSTEMD_LOG_TARGET</varname>, + <varname>$SYSTEMD_LOG_LEVEL</varname>, + <varname>$SYSTEMD_LOG_LOCATION</varname>, + <varname>$SYSTEMD_LOG_COLOR</varname> environment variables described above. + <varname>systemd.log_color</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, with the same effect as the + <option>--default-standard-output=</option> and + <option>--default-standard-error=</option> command line + arguments described above, respectively.</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/Documentation/cgroup-v2.txt">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>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>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</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..e47d36c --- /dev/null +++ b/man/sysusers.d.xml @@ -0,0 +1,297 @@ +<?xml version="1.0"?> +<!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> +<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> + </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</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. 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 create 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>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 syntax <literal><replaceable>uid</replaceable>:<replaceable>gid</replaceable></literal> is also supported to + allow creating user and group pairs with different numeric UID and GID values. The group with the indicated GID must get created explicitly before or it must already exist. Specifying <literal>-</literal> for the UID in this syntax + 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>/sbin/nologin</filename>, except if the UID of the user is 0, in + which case <filename>/bin/sh</filename> will be used.</para> + + <para>Only applies to lines of type <varname>u</varname> and should otherwise + be left unset (or <literal>-</literal>). It is recommended to omit this, unless + a shell different <filename>/sbin/nologin</filename> must be used.</para> + </refsect2> + </refsect1> + + <refsect1> + <title>Specifiers</title> + + <para>Specifiers can be used in the "Name", "ID", "GECOS", "Home directory", and "Shell" fields. + An unknown or unresolvable specifier is treated as invalid configuration. + The following expansions are understood:</para> + <table> + <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> + <row> + <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> + <entry><literal>%H</literal></entry> + <entry>Host name</entry> + <entry>The hostname of the running system.</entry> + </row> + <row> + <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> + <entry><literal>%T</literal></entry> + <entry>Directory for temporary files</entry> + <entry>This is either <filename>/tmp</filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to.</entry> + </row> + <row> + <entry><literal>%v</literal></entry> + <entry>Kernel release</entry> + <entry>Identical to <command>uname -r</command> output.</entry> + </row> + <row> + <entry><literal>%V</literal></entry> + <entry>Directory for larger and persistent temporary files</entry> + <entry>This is either <filename>/var/tmp</filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to.</entry> + </row> + <row> + <entry><literal>%%</literal></entry> + <entry>Escaped <literal>%</literal></entry> + <entry>Single percent sign.</entry> + </row> + </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/telinit.xml b/man/telinit.xml new file mode 100644 index 0000000..5a48caf --- /dev/null +++ b/man/telinit.xml @@ -0,0 +1,155 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<refentry id="telinit" + 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..7985f4a --- /dev/null +++ b/man/threads-aware.xml @@ -0,0 +1,17 @@ +<?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+ +--> + +<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..b75b4cc --- /dev/null +++ b/man/timedatectl.xml @@ -0,0 +1,315 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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 <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command> + </cmdsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para><command>timedatectl</command> may be used to query and + change the system clock and its settings.</para> + + <para>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 + <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. + </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>--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>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 through + <filename>systemd-timesyncd.service</filename> is active. Even if it is + inactive, a different service might still synchronize the clock. + If no command is specified, this is the implied default. + </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 existed + service listed in the environment variable <varname>$SYSTEMD_TIMEDATED_NTP_SERVICES</varname> + of <filename>systemd-timedated.service</filename>. If the argument is false, then this disables and + stops the all services listed in <varname>$SYSTEMD_TIMEDATED_NTP_SERVICES</varname>.</para></listitem> + </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> + </variablelist> + + </refsect2> + + </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..8ba639f --- /dev/null +++ b/man/timesyncd.conf.xml @@ -0,0 +1,109 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>5</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 <literal>[Time]</literal> 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..3f2ef7e --- /dev/null +++ b/man/tmpfiles.d.xml @@ -0,0 +1,769 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- + SPDX-License-Identifier: LGPL-2.1+ + + Copyright © 2010 Brandon Philips +--> +<refentry id="tmpfiles.d"> + + <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>…</filename> +<filename>/usr/share/user-tmpfiles.d/*.conf</filename> + </literallayout></para> + </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-cleanup.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, is 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. 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 and/or minus sign.</para> + + <para>The following line types are understood:</para> + + <variablelist> + <varlistentry> + <term><varname>f</varname></term> + <listitem><para>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. Does not follow symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>F</varname></term> + <listitem><para>Create or truncate a 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> + <listitem><para>Write the argument parameter to a file, if + the file exists. 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. Lines of this type + accept shell-style globs in place of normal path names. + This can be useful for setting SMACK labels. Does not follow + symlinks.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>T</varname></term> + <listitem><para>Recursively set extended attributes. Lines + of this type accept shell-style globs in place of normal + path names. This can be useful for setting SMACK + labels. Does not follow symlinks. </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>h</varname></term> + <listitem><para>Set file/directory attributes. Lines of this type + accept shell-style globs in place of normal path names.</para> + + <para>The format of the argument field is + <varname>[+-=][aAcCdDeijsStTu] </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>aAcCdDeijsStTu</literal> select the new + attributes for the files, see + <citerefentry project='man-pages'><refentrytitle>chattr</refentrytitle> + <manvolnum>1</manvolnum></citerefentry> for further information. + </para> + <para>Passing only <varname>=</varname> as argument resets + all the file attributes listed above. It has to be pointed + out that the <varname>=</varname> prefix limits itself to + the attributes corresponding to the letters listed here. All + other attributes will be left untouched. Does not follow + symlinks.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><varname>H</varname></term> + <listitem><para>Recursively set file/directory attributes. Lines + of this type accept shell-style globs in place of normal + path names. Does not follow symlinks. + </para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>a</varname></term> + <term><varname>a+</varname></term> + <listitem><para>Set POSIX ACLs (access control lists). If + suffixed with <varname>+</varname>, the specified entries will + be added to the existing set. + <command>systemd-tmpfiles</command> will automatically add + the required base entries for user and group based on the + access mode of the file, unless base entries already exist + or are explicitly specified. The mask will be added if not + specified explicitly or already present. Lines of this type + accept shell-style globs in place of normal path names. This + can be useful for allowing additional access to certain + files. Does not follow symlinks.</para></listitem> + </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 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 execute line with an + exclamation mark only if option <option>--boot</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 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> + </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> + </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> + <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> + <row> + <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> + <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>%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> + <row> + <entry><literal>%H</literal></entry> + <entry>Host name</entry> + <entry>The hostname of the running system.</entry> + </row> + <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 noindex='true'>/log</filename> appended, and <filename>/var/log</filename> otherwise.</entry> + </row> + <row> + <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> + <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> + <row> + <entry><literal>%T</literal></entry> + <entry>Directory for temporary files</entry> + <entry>This is either <filename>/tmp</filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to.</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>%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> + <row> + <entry><literal>%v</literal></entry> + <entry>Kernel release</entry> + <entry>Identical to <command>uname -r</command> output.</entry> + </row> + <row> + <entry><literal>%V</literal></entry> + <entry>Directory for larger and persistent temporary files</entry> + <entry>This is either <filename>/var/tmp</filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to.</entry> + </row> + <row> + <entry><literal>%%</literal></entry> + <entry>Escaped <literal>%</literal></entry> + <entry>Single percent sign.</entry> + </row> + </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..d1878f8 --- /dev/null +++ b/man/udev.conf.xml @@ -0,0 +1,120 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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>Specifes 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> + </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..74aab8e --- /dev/null +++ b/man/udev.xml @@ -0,0 +1,763 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ + 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 directory <filename>/usr/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 in <filename>/usr/lib</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-value pairs. + Each key has a distinct operation, depending on the used operator. Valid + operators are:</para> + <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> + + <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>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> + </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>Add a program to the list of programs to be executed after + processing all the rules for a specific event, depending on + <literal>type</literal>:</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>Starting daemons or other long-running processes is not appropriate + for udev; the forked processes, detached or not, will be unconditionally + killed after the event handling has finished.</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> + </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 <literal>type</literal>:</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> + </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 <literal>3</literal>. + </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> + </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..d4dc799 --- /dev/null +++ b/man/udev_device_get_syspath.xml @@ -0,0 +1,183 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..e27b770 --- /dev/null +++ b/man/udev_device_has_tag.xml @@ -0,0 +1,146 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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_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_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>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_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>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>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>XXX: Add short description.</para> + </refsect1>--> + + <refsect1> + <title>Return Value</title> + + <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> 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> + + <para>On success, <function>udev_device_has_tag()</function> + returns <constant>1</constant> or <constant>0</constant>, + depending on whether the device has the given tag or not. + 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_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..8e207b4 --- /dev/null +++ b/man/udev_device_new_from_syspath.xml @@ -0,0 +1,190 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..a45ca5d --- /dev/null +++ b/man/udev_enumerate_add_match_subsystem.xml @@ -0,0 +1,139 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..3ece35e --- /dev/null +++ b/man/udev_enumerate_new.xml @@ -0,0 +1,87 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..770ddb9 --- /dev/null +++ b/man/udev_enumerate_scan_devices.xml @@ -0,0 +1,109 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..0b1d28a --- /dev/null +++ b/man/udev_list_entry.xml @@ -0,0 +1,99 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..f5e4d07 --- /dev/null +++ b/man/udev_monitor_filter_update.xml @@ -0,0 +1,98 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..47fa5ab --- /dev/null +++ b/man/udev_monitor_new_from_netlink.xml @@ -0,0 +1,89 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..6a4aae9 --- /dev/null +++ b/man/udev_monitor_receive_device.xml @@ -0,0 +1,113 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..3971acb --- /dev/null +++ b/man/udev_new.xml @@ -0,0 +1,86 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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+ +--> + +<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..b7a2494 --- /dev/null +++ b/man/udevadm.xml @@ -0,0 +1,560 @@ +<?xml version='1.0'?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> + + <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 a device specification as a positional argument. 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. The default value is + <command>change</command>.</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, + the last <replaceable>NAME</replaceable> is used.</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, + the last <replaceable>NAME</replaceable> is used.</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, an optional positional argument can be used + to specify device name or sys path. It 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.</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> + </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. 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-priority=<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>string</replaceable></option></term> + <listitem> + <para>The action string.</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..4ad2d3b --- /dev/null +++ b/man/user-system-options.xml @@ -0,0 +1,55 @@ +<?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+ +--> + +<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, seperated 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..30af3c8 --- /dev/null +++ b/man/user@.service.xml @@ -0,0 +1,190 @@ +<?xml version="1.0"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> +<!-- SPDX-License-Identifier: LGPL-2.1+ --> + +<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> + <refpurpose>System units to manage user processes</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>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>, where the user's numerical UID + is used as the instance identifier. Each <command>systemd --user</command> instance manages a + hierarchy of its own units. See + <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> for + a discussion of systemd units and + <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>1</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.</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><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 a <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>8</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 + noindex='true'>/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 + noindex='true'>/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 + noindex='true'>/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 + noindex='true'>session-4.scope</filename>) and + <citerefentry><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry> + (<filename noindex='true'>session-19.scope</filename>), and also has a user manager instance + running (<filename noindex='true'>user@1000.service</filename>). User with UID 1001 is logged + in using <command>ssh</command> (<filename noindex='true'>session-20.scope</filename>) and + also has a user manager instance running (<filename + noindex='true'>user@1001.service</filename>). Those are all (leaf) system units, and form + part of the slice hierarchy, with <filename noindex='true'>user-1000.slice</filename> and + <filename noindex='true'>user-1001.slice</filename> below <filename + noindex='true'>user.slice</filename>. User units are visible below the + <filename>user@.service</filename> instances (<filename + noindex='true'>pulseaudio.service</filename>, <filename + noindex='true'>gnome-terminal-server.service</filename>, <filename + noindex='true'>init.scope</filename>, <filename noindex='true'>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/vconsole.conf.xml b/man/vconsole.conf.xml new file mode 100644 index 0000000..a0ca835 --- /dev/null +++ b/man/vconsole.conf.xml @@ -0,0 +1,147 @@ +<?xml version='1.0'?> <!--*-nxml-*--> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> + +<!-- + SPDX-License-Identifier: LGPL-2.1+ +--> + +<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> |