summaryrefslogtreecommitdiff
path: root/man
diff options
context:
space:
mode:
Diffstat (limited to 'man')
-rw-r--r--man/resolved.conf.xml17
-rw-r--r--man/sd_notify.xml9
-rw-r--r--man/systemctl.xml6
-rw-r--r--man/systemd-nspawn.xml155
-rw-r--r--man/systemd-resolve.xml13
-rw-r--r--man/systemd-resolved.service.xml95
-rw-r--r--man/systemd.exec.xml13
-rw-r--r--man/systemd.nspawn.xml18
-rw-r--r--man/systemd.unit.xml2
9 files changed, 230 insertions, 98 deletions
diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml
index 920ce9e89b..024ad6a9c1 100644
--- a/man/resolved.conf.xml
+++ b/man/resolved.conf.xml
@@ -202,6 +202,23 @@
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>Cache=</varname></term>
+ <listitem><para>Takes a boolean argument. If "yes" (the default),
+ resolving a domain name which already got queried earlier will re-use
+ the previous result as long as that is still valid, and thus does not
+ need to do an actual network request.</para>
+
+ <para>However, local caching slightly increases the chance of a
+ successful DNS poisoning attack, and might also be a privacy problem in
+ some environments: By measuring the time it takes to resolve a
+ particular network name, a user can determine whether any other user on
+ the same machine recently visited that name. If either of these is a
+ concern, you may disable the local caching. Be aware that this comes at
+ a performance cost, which is <emphasis>very</emphasis> high with DNSSEC.
+ </para></listitem>
+ </varlistentry>
+
</variablelist>
</refsect1>
diff --git a/man/sd_notify.xml b/man/sd_notify.xml
index bd6cfdcd29..025fbec6c1 100644
--- a/man/sd_notify.xml
+++ b/man/sd_notify.xml
@@ -250,6 +250,15 @@
restrictions, it is ignored.</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>
+
</variablelist>
<para>It is recommended to prefix variable names that are not
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 914af929c8..742da81cfe 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -481,6 +481,9 @@
<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
@@ -1303,6 +1306,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
<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>
diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index 08122795f4..c436f42948 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -67,69 +67,82 @@
<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> 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>. 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>Note that even though these security precautions are taken
- <command>systemd-nspawn</command> is not suitable for fully secure
- container setups. Many of the security features may be
- circumvented and are hence primarily useful to avoid accidental
- changes to the host system from the container.</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
+ <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>Like <citerefentry
+ project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry> the
+ <command>systemd-nspawn</command> 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 in a couple of locations, most importantly in
+ <filename>/var/lib/machines</filename>, the suggested directory to place 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.</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> command to request an additional login
- prompt in a running container.</para>
-
- <para><command>systemd-nspawn</command> implements the
- <ulink
- url="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container
- Interface</ulink> specification.</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
+ <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 commnd line. Most importanly 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 dalong 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="http://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>
@@ -139,7 +152,7 @@
are used as arguments for the init binary. 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>-b</option> is not used and
+ arguments for this program. If <option>--boot</option> is not used and
no arguments are specified, a shell is launched in the
container.</para>
@@ -310,6 +323,9 @@
</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>
@@ -446,7 +462,10 @@
<listitem><para>If the kernel supports the user namespaces feature, equivalent to
<option>--private-users=pick</option>, otherwise equivalent to
- <option>--private-users=no</option>.</para></listitem>
+ <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></listitem>
</varlistentry>
<varlistentry>
@@ -540,6 +559,9 @@
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>
@@ -705,7 +727,10 @@
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></listitem>
+ <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>
@@ -981,10 +1006,10 @@
</varlistentry>
<varlistentry>
- <term><varname>--notify-ready=</varname></term>
+ <term><option>--notify-ready=</option></term>
<listitem><para>Configures support for notifications from the container's init process.
- <varname>--notify-ready=</varname> takes a boolean (<option>no</option> and <option>yes</option>).
+ <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
diff --git a/man/systemd-resolve.xml b/man/systemd-resolve.xml
index b917ac20a2..ca26bb4d49 100644
--- a/man/systemd-resolve.xml
+++ b/man/systemd-resolve.xml
@@ -114,6 +114,12 @@
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>
+
<para>The <option>--type=</option> switch may be used to specify a DNS resource record type (A, AAAA, SOA, MX, ...) in
order to request a specific DNS resource record, instead of the address or reverse address lookups.
The special value <literal>help</literal> may be used to list known values.</para>
@@ -294,8 +300,15 @@
<listitem><para>Flushes all DNS resource record caches the service maintains locally.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><option>--status</option></term>
+
+ <listitem><para>Shows the global and per-link DNS settings in currently in effect.</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>
diff --git a/man/systemd-resolved.service.xml b/man/systemd-resolved.service.xml
index 485f3e9aee..0df037ba69 100644
--- a/man/systemd-resolved.service.xml
+++ b/man/systemd-resolved.service.xml
@@ -58,27 +58,45 @@
<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 resolver and
- responder. In addition it 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>.</para>
-
- <para>The glibc NSS module
- <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry> is required to
- permit glibc's NSS resolver functions to resolve host names via <command>systemd-resolved</command>.</para>
-
- <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,
- and the per-link dynamic settings received over DHCP. See
- <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- and
- <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
- for details. 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/resolv.conf</filename> (see above).</para>
+ 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="http://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><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><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><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 <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><command>systemd-resolved</command> synthesizes DNS RRs for the following cases:</para>
+ <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, the per-link dynamic settings received over DHCP 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/resolv.conf</filename> (see below).</para>
+
+ <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
@@ -137,15 +155,46 @@
per-interface domains are exclusively routed to the matching
interfaces.</para>
- <para>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>.</para>
-
<para>See the <ulink url="http://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>Three modes of handling <filename>/etc/resolv.conf</filename> (see
+ <citerefentry><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>) are
+ supported:</para>
+
+ <itemizedlist>
+ <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 mode of operation is recommended.</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>
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index dbfc7692f7..ed02666daf 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -1413,6 +1413,19 @@
</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><refentrytitle>sched</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details about
+ these scheduling policies. 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>
+
</variablelist>
</refsect1>
diff --git a/man/systemd.nspawn.xml b/man/systemd.nspawn.xml
index 6df4aeb2a9..b1344d6c10 100644
--- a/man/systemd.nspawn.xml
+++ b/man/systemd.nspawn.xml
@@ -146,7 +146,8 @@
specified parameters using <varname>Parameters=</varname> are passed as additional arguments to the
<filename>init</filename> process. This setting corresponds to the <option>--boot</option> switch on the
<command>systemd-nspawn</command> command line. This option may not be combined with
- <varname>ProcessTwo=yes</varname>.</para></listitem>
+ <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>
@@ -257,7 +258,8 @@
<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). </para></listitem>
+ (see above). This option is the default if the <filename>systemd-nspawn@.service</filename> template unit file
+ is used.</para></listitem>
</varlistentry>
<varlistentry>
@@ -367,13 +369,11 @@
<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).</para></listitem>
+ <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>
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 341789cd47..85a7b12d76 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -1234,7 +1234,7 @@
<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 prefix name prepended with <filename>/</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>.</entry>
</row>
<row>
<entry><literal>%c</literal></entry>
generated by cgit v1.2.3-54-g00ecf (git 2.45.2) at 2025-05-31 19:02:55 +0000