This is almost all of #17177.
<listitem><para>Read the user's JSON record from the specified file. If passed as
<literal>-</literal> read the user record from standard input. The supplied JSON object must follow
- the structure documented
on <ulink url="https://systemd.io/USER_RECORD">JSON User Records</ulink>.
+ the structure documented
in <ulink url="https://systemd.io/USER_RECORD">JSON User Records</ulink>.
This option may be used in conjunction with the <command>create</command> and
<command>update</command> commands (see below), where it allows configuring the user record in JSON
as-is, instead of setting the individual user record properties (see below).</para></listitem>
<listitem><para>Takes a password hint to store alongside the user record. This string is stored
accessible only to privileged users and the user itself and may not be queried by other users.
- Example: <option>--password-hint="My first pet's name"</option></para></listitem>
+ Example: <option>--password-hint="My first pet's name"</option>.</para></listitem>
</varlistentry>
<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
+ <listitem><para>Query the user for locale, keymap, timezone, hostname,
+ root's password, and root's shell. This is equivalent to specifying
<option>--prompt-locale</option>,
<option>--prompt-keymap</option>,
<option>--prompt-timezone</option>,
For more information please consult
<citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>
and
- <citerefentry><refentrytitle>org.freedesktop.machine1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ <citerefentry><refentrytitle>org.freedesktop.machine1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
and
- <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
<para>A small companion daemon
<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>
+ <listitem><para>Specifies the file system type to mount (e.g. <literal>vfat</literal> or
+ <literal>ext4</literal>). If omitted or set to <literal>auto</literal>, the file system type is
+ determined automatically.</para></listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><option>--no-block</option></term>
- <listitem><para>Do not synchronously wait for the requested operation to finish.
- Use of this option is only recommended when <command>systemd-notify</command>
- is spawned by the service manager, or when the invoking process is directly spawned
- by the service manager and has enough privileges to allow <command>systemd-notify
- </command> to send the notification on its behalf. Sending notifications with
+ <listitem><para>Do not synchronously wait for the requested operation to finish. Use of this option
+ is only recommended when <command>systemd-notify</command> is spawned by the service manager, or when
+ the invoking process is directly spawned by the service manager and has enough privileges to allow
+ <command>systemd-notify</command> to send the notification on its behalf. Sending notifications with
this option set is prone to race conditions in all other cases.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>RootHashSignature=</varname></term>
- <listitem><para>Takes a PKCS7 formatted binary signature of the <varname>RootHash=</varname> option as a path
- to a DER encoded signature file or as an ASCII base64 string encoding of the DER encoded signature, prefixed
- by <literal>base64:</literal>. The dm-verity volume will only be opened if the signature of the root hash
- signature is valid and created by a public key present in the kernel keyring. If this option is not specified,
- but a file with the <filename>.roothash.p7s</filename> suffix is found next to the image file, bearing otherwise
- the same name (except if the image has the <filename>.raw</filename> suffix, in which case the signature file
- must not have it in its name), the signature is read from it and automatically used.</para>
+ <listitem><para>Takes a PKCS7 signature of the <varname>RootHash=</varname> option as a path to a
+ DER-encoded signature file, or as an ASCII base64 string encoding of a DER-encoded signature prefixed
+ by <literal>base64:</literal>. The dm-verity volume will only be opened if the signature of the root
+ hash is valid and signed by a public key present in the kernel keyring. If this option is not
+ specified, but a file with the <filename>.roothash.p7s</filename> suffix is found next to the image
+ file, bearing otherwise the same name (except if the image has the <filename>.raw</filename> suffix,
+ in which case the signature file must not have it in its name), the signature is read from it and
+ automatically used.</para>
<para>If the disk image contains a separate <filename>/usr/</filename> partition it may also be
Verity protected, in which case the signature for the root hash may configured via a
<listitem><para>Takes a profile name as argument. The process executed by the unit will switch to
this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If
prefixed by <literal>-</literal>, all errors will be ignored. This setting has no effect if AppArmor
- is not enabled. This setting not affect commands prefixed with <literal>+</literal>.</para>
+ is not enabled. This setting does not affect commands prefixed with <literal>+</literal>.</para>
</listitem>
</varlistentry>
<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>
+ <listitem><para>These options take a whitespace-separated list of directory names. The specified
+ directory names must be relative, and may not include <literal>..</literal>. If set, when the unit is
+ started, one or more directories by the specified names will be created (including their parents)
+ below the locations defined in the following table. Also, the corresponding environment variable will
+ be defined with the full paths of the directories. If multiple directories are set, then in the
+ environment variable the paths are concatenated with colon (<literal>:</literal>).</para>
<table>
<title>Automatic directory creation and environment variables</title>
<tgroup cols='4'>
<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
+ <listitem><para>Sets up a new file system namespace for executed processes. These options may be used
+ to limit access a process has to the file system. Each setting takes a space-separated list of paths
+ relative to the host's root directory (i.e. the system running the service manager). Note that if
+ paths contain symlinks, they are resolved relative to the root directory set with
<varname>RootDirectory=</varname>/<varname>RootImage=</varname>.</para>
<para>Paths listed in <varname>ReadWritePaths=</varname> are accessible from within the namespace
<varlistentry>
<term><varname>$LOG_NAMESPACE</varname></term>
- <listitem><para>If the <varname>LogNamespace=</varname> service setting is used, contains name of the
- selected logging namespace.</para></listitem>
+ <listitem><para>Contains the name of the selected logging namespace when the
+ <varname>LogNamespace=</varname> service setting is used.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>_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>
+ <para>The control group path in the systemd hierarchy, the systemd slice unit name, the systemd
+ unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and
+ the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry
+ originates from.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>_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>
+ <para>The kernel device name. If the entry is associated to a block device, contains the major and
+ minor numbers of the device node, separated by <literal>:</literal> and prefixed by
+ <literal>b</literal>. Similarly for character devices, but prefixed by <literal>c</literal>. For
+ network devices, this is the interface index prefixed by <literal>n</literal>. For all other
+ devices, this is the subsystem name prefixed by <literal>+</literal>, followed by
+ <literal>:</literal>, followed by the kernel device name.</para>
</listitem>
</varlistentry>
<varlistentry>
<refsect1>
<title>[MACVTAP] Section Options</title>
- <para>The [MACVTAP] section applies for
- netdevs of kind <literal>macvtap</literal> and accepts the
- same key as [MACVLAN].</para>
+ <para>The [MACVTAP] section applies for netdevs of kind <literal>macvtap</literal> and accepts the same
+ keys as [MACVLAN].</para>
</refsect1>
<refsect1>
<refsect1>
<title>[IPVTAP] Section Options</title>
- <para>The [IPVTAP] section only applies for
- netdevs of kind <literal>ipvtap</literal> and accepts the
- same key as [IPVLAN].</para>
+ <para>The [IPVTAP] section only applies for netdevs of kind <literal>ipvtap</literal> and accepts the
+ same keys as [IPVLAN].</para>
</refsect1>
<refsect1>
<varlistentry>
<term><varname>IPDoNotFragment=</varname></term>
<listitem>
- <para>Accepts the same key in [VXLAN] section.</para>
+ <para>Accepts the same key as in [VXLAN] section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>PeerTunnelId=</varname></term>
<listitem>
<para>Specifies the peer tunnel id. Takes a number in the range 1—4294967295. The value used must
- match the <literal>PeerTunnelId=</literal> value being used at the peer. This setting is
- compulsory.</para>
+ match the <literal>TunnelId=</literal> value being used at the peer. This setting is compulsory.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><varname>Port=</varname></term>
<listitem>
- <para>Accepts the same key in [MACsecReceiveChannel] section.</para>
+ <para>Accepts the same key as in [MACsecReceiveChannel] section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>MACAddress=</varname></term>
<listitem>
- <para>Accepts the same key in [MACsecReceiveChannel] section.</para>
+ <para>Accepts the same key as in [MACsecReceiveChannel] section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>PacketNumber=</varname></term>
<listitem>
- <para>Accepts the same key in [MACsecTransmitAssociation] section.</para>
+ <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>KeyId=</varname></term>
<listitem>
- <para>Accepts the same key in [MACsecTransmitAssociation] section.</para>
+ <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>Key=</varname></term>
<listitem>
- <para>Accepts the same key in [MACsecTransmitAssociation] section.</para>
+ <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>KeyFile=</varname></term>
<listitem>
- <para>Accepts the same key in [MACsecTransmitAssociation] section.</para>
+ <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>Activate=</varname></term>
<listitem>
- <para>Accepts the same key in [MACsecTransmitAssociation] section.</para>
+ <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
</listitem>
</varlistentry>
</variablelist>
<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
+ <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
<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>
+ <para>Specifies the port number where the encapsulated packets will arrive. Those packets will be
+ removed and manually fed back into the network stack with the encapsulation removed to be sent to
+ the real destination. This option is mandatory.</para>
</listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><varname>RequestOptions=</varname></term>
<listitem>
- <para>When configured, allows to set arbitrary request options in the DHCPv6 request options list and will
- sent to the DHCPV6 server. A whitespace-separated list of integers in the range 1..254. Defaults to unset.</para>
+ <para>When configured, allows to set arbitrary request options in the DHCPv6 request options list
+ that will be sent to the DHCPV6 server. A whitespace-separated list of integers in the range
+ 1..254. Defaults to unset.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>UseOnLinkPrefix=</varname></term>
<listitem>
- <para>When true (the default), the onlink prefix received in the Router Advertisement will be used and take
- precedence over any statically configured ones.</para>
+ <para>When true (the default), the onlink prefix received in the Router Advertisement will be
+ used and takes precedence over any statically configured ones.</para>
</listitem>
</varlistentry>
<refsect1>
<title>[LLDP] Section Options</title>
<para>The [LLDP] section manages the Link Layer Discovery Protocol (LLDP) and accepts the following
- keys.</para>
+ keys:</para>
<variablelist class='network-directives'>
<varlistentry>
<term><varname>MUDURL=</varname></term>
<varlistentry>
<term><varname>LimitBytes=</varname></term>
<listitem>
- <para>Specifies the hard limit on the FIFO size in bytes. The size limit (a buffer size) to prevent
- it from overflowing in case it is unable to dequeue packets as quickly as it receives them. When
- this limit is reached, incoming packets are dropped. When suffixed with K, M, or G, the specified
- size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults
- to unset and kernel's default is used.</para>
+ <para>Specifies the hard limit in bytes on the FIFO buffer size. The size limit prevents overflow
+ in case the kernel is unable to dequeue packets as quickly as it receives them. When this limit is
+ reached, incoming packets are dropped. When suffixed with K, M, or G, the specified size is parsed
+ as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and
+ kernel default is used.</para>
</listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term><varname>PriorityMap=</varname></term>
<listitem>
- <para>The priority map maps the priority of a packet to a band. The argument is a white-space
- separated list of numbers. The first number indicates which band the packets with priority
- 0 should be put to, the second is for priority 1, and so on. There can be up to 16 numbers in
- the list. If there are fewer, the default band that traffic with one of the unmentioned
- priorities goes to is the last one. Each band number must be 0..255. This setting can be
- specified multiple times. If an empty string is assigned, then the all previous assignments
- are cleared.</para>
+ <para>The priority map maps the priority of a packet to a band. The argument is a whitespace
+ separated list of numbers. The first number indicates which band the packets with priority 0 should
+ be put to, the second is for priority 1, and so on. There can be up to 16 numbers in the list. If
+ there are fewer, the default band that traffic with one of the unmentioned priorities goes to is
+ the last one. Each band number must be in the range 0..255. This setting can be specified multiple
+ times. If an empty string is assigned, then the all previous assignments are cleared.</para>
</listitem>
</varlistentry>
</variablelist>
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.
+ absolute file system path of a FunctionFS mount point as the argument.
Behavior otherwise is very similar to the <varname>ListenFIFO=</varname>
directive above. Use this to open the FunctionFS endpoint
<filename>ep0</filename>. When using this option, the
<citerefentry><refentrytitle>systemd-xdg-autostart-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for the XDG desktop files in autostart directories.
Desktop Environments can opt-in to use this service by adding a <varname>Wants=</varname>
- dependency on <literal>xdg-desktop-autostart.target</literal></para>.
+ dependency on <literal>xdg-desktop-autostart.target</literal>.</para>
</listitem>
</varlistentry>
</variablelist>
<para>These variables may contain a list of paths, separated by colons
(<literal>:</literal>). When set, if the list ends with an empty
component (<literal>...:</literal>), this list is prepended to the
- usual set of of paths. Otherwise, the specified list replaces the usual
+ usual set of paths. Otherwise, the specified list replaces the usual
set of paths.
</para></listitem>
</varlistentry>
<listitem><para>Controls log output, with the same effect as the
<varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>,
<varname>$SYSTEMD_LOG_LOCATION</varname>, <varname>$SYSTEMD_LOG_TARGET</varname>,
- <varname>$SYSTEMD_LOG_TIME</varname>, <varname>$SYSTEMD_LOG_TID</varname> environment variables
- described above. <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>,
- <varname>systemd.log_time</varname> and <varname>systemd.log_tid=</varname> can be specified without
+ <varname>$SYSTEMD_LOG_TIME</varname>, and <varname>$SYSTEMD_LOG_TID</varname> environment variables
+ described above. <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>,
+ <varname>systemd.log_time</varname>, and <varname>systemd.log_tid=</varname> can be specified without
an argument, with the same effect as a positive boolean.</para></listitem>
</varlistentry>
<para>Those options correspond directly to options listed above in "Kernel Command Line". Both forms
may be used equivalently for the system manager, but it is recommended to use the forms listed above in
this context, because they are properly namespaced. When an option is specified both on the kernel
- command line, and as a normal command line argument, the latter has higher precedence.</para>
+ command line and as a normal command line argument, the latter has higher precedence.</para>
<para>When <command>systemd</command> is used as a user manager, the kernel command line is ignored and
only the options described below are understood. Nevertheless, <command>systemd</command> is usually
projects / thirdparty / systemd.git / commitdiff
