picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Merge pull request #17238 from keszybz/man-tmp-noexec 

Say that noexec should not be used for /tmp
This commit is contained in:
Lennart Poettering 2020-10-07 09:45:58 +02:00 committed by GitHub
parent ab582fda48 806d919cb5
commit 85585b767d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
57 changed files with 289 additions and 281 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/TEMPORARY_DIRECTORIES.md
View File

@ -1,10 +1,10 @@
---
title: Using /tmp/ And /var/tmp/ Safely
title: Using /tmp/ and /var/tmp/ Safely
category: Interfaces
layout: default
---
# Using `/tmp/` And `/var/tmp/` Safely
# Using `/tmp/` and `/var/tmp/` Safely
`/tmp/` and `/var/tmp/` are two world-writable directories Linux systems
provide for temporary files. The former is typically on `tmpfs` and thus

2
man/bootup.xml
View File

@ -227,7 +227,7 @@ emergency.service | | |
<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
<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

4
man/busctl.xml
View File

@ -357,9 +357,9 @@
<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
<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
<filename>/proc/</filename> might be more recent than the rest of
the credential information. Defaults to <literal>yes</literal>.</para>
</listitem>
</varlistentry>

66
man/file-hierarchy.xml
View File

@ -127,20 +127,23 @@
<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
<filename>/var/tmp/</filename> for larger files.) This directory is usually flushed at boot-up. Also,
files that are not accessed within a certain time may be automatically deleted.</para>
<para>If applications find the environment variable <varname>$TMPDIR</varname> set, they should use
the directory specified in it instead of <filename>/tmp/</filename> (see <citerefentry
project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
<ulink url="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">IEEE
Std 1003.1</ulink> for details). For further details about this directory, see <ulink
url="https://systemd.io/TEMPORARY_DIRECTORIES">Using /tmp/ And /var/tmp/
Safely</ulink>.</para></listitem>
Std 1003.1</ulink> for details).</para>
<para>Since <filename>/tmp/</filename> is accessible to other users of the system, it is essential
that files and subdirectories under this directory are only created with <citerefentry
project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry
project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
and similar calls. For more details, see <ulink url="https://systemd.io/TEMPORARY_DIRECTORIES">Using
/tmp/ and /var/tmp/ Safely</ulink>.</para>
</listitem>
</varlistentry>
</variablelist>
@ -334,20 +337,22 @@
<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
and can thus accept larger files. (Use <filename>/tmp/</filename> for small ephemeral files.) This
directory is generally not flushed at boot-up, but time-based cleanup of files that have not been
accessed for a certain time is applied.</para>
<para>If applications find the environment variable <varname>$TMPDIR</varname> set, they should use
the directory specified in it instead of <filename>/var/tmp/</filename> (see <citerefentry
project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
details).</para>
<para>The same security restrictions as with <filename>/tmp/</filename> apply: <citerefentry
project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry
project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry> 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). For further details about this directory, see <ulink
url="https://systemd.io/TEMPORARY_DIRECTORIES">Using /tmp/ And /var/tmp/
Safely</ulink>.</para></listitem>
project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
and similar calls should be used. For further details about this directory, see <ulink
url="https://systemd.io/TEMPORARY_DIRECTORIES">Using /tmp/ and /var/tmp/ Safely</ulink>.</para>
</listitem>
</varlistentry>
</variablelist>
@ -584,6 +589,19 @@
directives of service units (see
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details).</para>
<para><filename>/tmp/</filename>, <filename>/var/tmp/</filename> and <filename>/dev/shm/</filename>
should be mounted <option>nosuid</option> and <option>nodev</option>, which means that set-user-id mode
and character or block special devices are not interpreted on those file systems. In general it is not
possible to mount them <option>noexec</option>, because various programs use those directories for
dynamically generated or optimized code, and with that flag those use cases would break. Using this flag
is OK on special-purpose installations or systems where all software that may be installed is known and
doesn't require such functionality. See the discussion of
<option>nosuid</option>/<option>nodev</option>/<option>noexec</option> in <citerefentry
project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> and
<constant>PROT_EXEC</constant> in <citerefentry
project='man-pages'><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
</para>
</refsect1>
<refsect1>

8
man/hwdb.xml
View File

@ -31,12 +31,12 @@
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>
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
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>,
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>

2
man/journald.conf.xml
View File

@ -216,7 +216,7 @@
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,
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

8
man/kernel-command-line.xml
View File

@ -131,15 +131,15 @@
<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
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
<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
configuration and no stored state in effect, as <filename>/etc/</filename> and <filename>/var/</filename> (as
well as all other resources shipped in the root file system) are reset at boot and lost on shutdown. If this
setting is set to <literal>state</literal> the root file system is mounted read-only, however
<filename>/var</filename> is mounted as a volatile memory file system (<literal>tmpfs</literal>), so that the
<filename>/var/</filename> is mounted as a volatile memory file system (<literal>tmpfs</literal>), so that the
system boots up with the normal configuration applied, but all state reset at boot and lost at shutdown. If
this setting is set to <literal>overlay</literal> the root file system is set up as
<literal>overlayfs</literal> mount combining the read-only root directory with a writable

2
man/loginctl.xml
View File

@ -238,7 +238,7 @@
<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,
<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

2
man/machine-id.xml
View File

@ -111,7 +111,7 @@
<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
<filename>/etc/machine-id</filename> or <filename>/etc/</filename> are read-only during
early boot but become writable later on.</para>
</refsect1>

12
man/machinectl.xml
View File

@ -64,8 +64,8 @@
<itemizedlist>
<listitem><para>Directory trees containing an OS, including the
top-level directories <filename>/usr</filename>,
<filename>/etc</filename>, and so on.</para></listitem>
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>
@ -440,11 +440,11 @@
<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
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>
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,
@ -562,7 +562,7 @@
<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
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
@ -890,7 +890,7 @@
<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
<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>

2
man/nss-myhostname.xml
View File

@ -57,7 +57,7 @@
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
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

2
man/org.freedesktop.import1.xml
View File

@ -156,7 +156,7 @@ node /org/freedesktop/import1 {
operation (as in that case we know the total size on disk). If a socket or pipe is specified, progress information is not
available. The file descriptor argument is followed by a local name for the image. This should be a
name suitable as a hostname and will be used to name the imported image below
<filename>/var/lib/machines</filename>. A tar import is placed as a directory tree or a
<filename>/var/lib/machines/</filename>. A tar import is placed as a directory tree or a
<citerefentry project="man-pages"><refentrytitle>btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
subvolume below <filename>/var/lib/machines/</filename> under the specified name with no suffix
appended. A raw import is placed as a file in <filename>/var/lib/machines/</filename> with the

2
man/org.freedesktop.login1.xml
View File

@ -504,7 +504,7 @@ node /org/freedesktop/login1 {
stored on disk.</para>
<para><function>AttachDevice()</function> may be used to assign a specific device to a specific
seat. The device is identified by its <filename>/sys</filename> path and must be eligible for seat
seat. The device is identified by its <filename>/sys/</filename> path and must be eligible for seat
assignments. <function>AttachDevice()</function> takes three arguments: the seat id, the sysfs path,
and a boolean for controlling polkit interactivity (see below). Device assignments are persistently
stored on disk. To create a new seat, simply specify a previously unused seat id. For more information

18
man/org.freedesktop.systemd1.xml
View File

@ -1288,11 +1288,11 @@ node /org/freedesktop/systemd1 {
file.</para>
<para><function>EnableUnitFiles()</function> may be used to enable one or more units in the system (by
creating symlinks to them in <filename>/etc</filename> or <filename>/run</filename>). It takes a list
creating symlinks to them in <filename>/etc/</filename> or <filename>/run/</filename>). It takes a list
of unit files to enable (either just file names or full absolute paths if the unit files are residing
outside the usual unit search paths) and two booleans: the first controls whether the unit shall be
enabled for runtime only (true, <filename>/run</filename>), or persistently (false,
<filename>/etc</filename>). The second one controls whether symlinks pointing to other units shall be
enabled for runtime only (true, <filename>/run/</filename>), or persistently (false,
<filename>/etc/</filename>). The second one controls whether symlinks pointing to other units shall be
replaced if necessary. This method returns one boolean and an array of the changes made. The boolean
signals whether the unit files contained any enablement information (i.e. an [Install]) section. The
changes array consists of structures with three strings: the type of the change (one of
@ -1301,7 +1301,7 @@ node /org/freedesktop/systemd1 {
format.</para>
<para>Similarly, <function>DisableUnitFiles()</function> disables one or more units in the system,
i.e. removes all symlinks to them in <filename>/etc</filename> and <filename>/run</filename>.</para>
i.e. removes all symlinks to them in <filename>/etc/</filename> and <filename>/run/</filename>.</para>
<para>The <function>EnableUnitFilesWithFlags()</function> and <function>DisableUnitFilesWithFlags()</function>
take in options as flags instead of booleans to allow for extendability, defined as follows:</para>
@ -1425,7 +1425,7 @@ node /org/freedesktop/systemd1 {
flag. Taints may be used to lower the chance of bogus bug reports. The following taints are currently
known: <literal>split-usr</literal>, <literal>mtab-not-symlink</literal>,
<literal>cgroups-missing</literal>, <literal>local-hwclock</literal>. <literal>split-usr</literal> is
set if <filename>/usr</filename> is not pre-mounted when systemd is first invoked. See
set if <filename>/usr/</filename> is not pre-mounted when systemd is first invoked. See
<ulink url="http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken">
Booting Without /usr is Broken</ulink>
for details why this is bad. <literal>mtab-not-symlink</literal> indicates that
@ -2094,11 +2094,11 @@ node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
<literal>disabled</literal>, and <literal>invalid</literal>. <literal>enabled</literal> indicates that a
unit file is permanently enabled. <literal>enable-runtime</literal> indicates the unit file is only
temporarily enabled and will no longer be enabled after a reboot (that means, it is enabled via
<filename>/run</filename> symlinks, rather than <filename>/etc</filename>). <literal>linked</literal>
indicates that a unit is linked into <filename>/etc</filename> permanently. <literal>linked-runtime</literal>
indicates that a unit is linked into <filename>/run</filename> temporarily (until the next
<filename>/run/</filename> symlinks, rather than <filename>/etc/</filename>). <literal>linked</literal>
indicates that a unit is linked into <filename>/etc/</filename> permanently. <literal>linked-runtime</literal>
indicates that a unit is linked into <filename>/run/</filename> temporarily (until the next
reboot). <literal>masked</literal> indicates that the unit file is masked permanently.
<literal>masked-runtime</literal> indicates that it is masked in <filename>/run</filename> temporarily
<literal>masked-runtime</literal> indicates that it is masked in <filename>/run/</filename> temporarily
(until the next reboot). <literal>static</literal> indicates that the unit is statically enabled, i.e.
always enabled and doesn't need to be enabled explicitly. <literal>invalid</literal> indicates that it
could not be determined whether the unit file is enabled.</para>

2
man/os-release.xml
View File

@ -59,7 +59,7 @@
<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
<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>

4
man/sd-login.xml
View File

@ -46,8 +46,8 @@
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
<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>

4
man/sd_bus_creds_new_from_pid.xml
View File

@ -183,7 +183,7 @@
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
<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
@ -243,7 +243,7 @@
<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
<filename>/proc/</filename>, and are thus not suitable for
authorization decisions.</para>
<para><function>sd_bus_creds_ref()</function> always returns the

2
man/sd_is_fifo.xml
View File

@ -158,7 +158,7 @@
<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>
<filename>/proc/</filename> or <filename>/sys/</filename>.</para>
</refsect1>
<refsect1>

2
man/sd_notify.xml
View File

@ -222,7 +222,7 @@
<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
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

2
man/sd_pid_get_owner_uid.xml
View File

@ -232,7 +232,7 @@
<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>,
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>

10
man/standard-specifiers.xml
View File

@ -39,11 +39,21 @@
<entry>Operating system ID</entry>
<entry>The operating system identifier of the running system, as read from the <varname>ID=</varname> field of <filename>/etc/os-release</filename>. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
</row>
<row id='T'>
<entry><literal>%T</literal></entry>
<entry>Directory for temporary files</entry>
<entry>This is either <filename>/tmp<!-- no / --></filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to. (Note that the directory may be specified without a trailing slash.)</entry>
</row>
<row id='v'>
<entry><literal>%v</literal></entry>
<entry>Kernel release</entry>
<entry>Identical to <command>uname -r</command> output.</entry>
</row>
<row id='V'>
<entry><literal>%V</literal></entry>
<entry>Directory for larger and persistent temporary files</entry>
<entry>This is either <filename>/var/tmp<!-- no / --></filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to. (Note that the directory may be specified without a trailing slash.)</entry>
</row>
<row id='w'>
<entry><literal>%w</literal></entry>
<entry>Operating system version ID</entry>

16
man/systemctl.xml
View File

@ -663,7 +663,7 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
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
<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
@ -901,7 +901,7 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
<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
(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>
@ -916,10 +916,10 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
<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
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
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
@ -970,7 +970,7 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
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
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
@ -982,8 +982,8 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
<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>
<filename>/etc/</filename>, since they take precedence over
<filename>/run/</filename>.</para>
</listitem>
</varlistentry>
@ -2100,7 +2100,7 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
(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>,
<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>

2
man/systemd-cgls.xml
View File

@ -46,7 +46,7 @@
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
<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>

10
man/systemd-delta.xml
View File

@ -34,9 +34,9 @@
<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
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>
@ -54,8 +54,8 @@
<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
(<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

2
man/systemd-firstboot.xml
View File

@ -38,7 +38,7 @@
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 satisfied. This essentially means that <filename>/etc/</filename>
is empty, see
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details.</para>

28
man/systemd-fstab-generator.xml
View File

@ -110,7 +110,7 @@
<varlistentry>
<term><varname>mount.usr=</varname></term>
<listitem><para>Takes the <filename>/usr</filename> filesystem
<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
@ -118,7 +118,7 @@
<varname>root=</varname>.</para>
<para>Otherwise, this parameter defaults to the
<filename>/usr</filename> entry found in
<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.
@ -128,7 +128,7 @@
<varlistentry>
<term><varname>mount.usrfstype=</varname></term>
<listitem><para>Takes the <filename>/usr</filename> filesystem
<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
@ -136,7 +136,7 @@
set in <varname>rootfstype=</varname>.</para>
<para>Otherwise, this value will be read from the
<filename>/usr</filename> entry in
<filename>/usr/</filename> entry in
<filename>/etc/fstab</filename> on the root filesystem.</para>
<para><varname>mount.usrfstype=</varname> is honored by the
@ -146,14 +146,14 @@
<varlistentry>
<term><varname>mount.usrflags=</varname></term>
<listitem><para>Takes the <filename>/usr</filename> filesystem
<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>/usr/</filename> entry in
<filename>/etc/fstab</filename> on the root filesystem.</para>
<para><varname>mount.usrflags=</varname> is honored by the
@ -173,15 +173,15 @@
<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
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
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
however will mount a <literal>tmpfs</literal> file system to <filename>/var/</filename>. In this mode the normal
system configuration (i.e. the contents of <literal>/etc/</literal>) is in effect (and may be modified during
system runtime), however the system state (i.e. the contents of <literal>/var/</literal>) is reset at boot and
lost at shutdown.</para>
<para>If this setting is set to <literal>overlay</literal> the root file system is set up as
@ -189,13 +189,13 @@
<literal>tmpfs</literal>, so that no modifications are made to disk, but the file system may be modified
nonetheless with all changes being lost at reboot.</para>
<para>Note that in none of these modes the root directory, <filename>/etc</filename>, <filename>/var</filename>
<para>Note that in none of these modes the root directory, <filename>/etc/</filename>, <filename>/var/</filename>
or any other resources stored in the root file system are physically removed. It's thus safe to boot a system
that is normally operated in non-volatile mode temporarily into volatile mode, without losing data.</para>
<para>Note that with the exception of <literal>overlay</literal> mode, enabling this setting will only work
correctly on operating systems that can boot up with only <filename>/usr</filename> mounted, and are able to
automatically populate <filename>/etc</filename>, and also <filename>/var</filename> in case of
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>

6
man/systemd-journald.service.xml
View File

@ -179,8 +179,8 @@ systemd-tmpfiles --create --prefix /var/log/journal</programlisting>
<listitem><para>Request that journal data from <filename>/run/</filename> is flushed to
<filename>/var/</filename> in order to make it persistent (if this is enabled). This must be used
after <filename>/var/</filename> is mounted, as otherwise log data from <filename>/run</filename> is
never flushed to <filename>/var</filename> regardless of the configuration. Use the
after <filename>/var/</filename> is mounted, as otherwise log data from <filename>/run/</filename> is
never flushed to <filename>/var/</filename> regardless of the configuration. Use the
<command>journalctl --flush</command> command to request flushing of the journal files, and wait for
the operation to complete. See
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
@ -292,7 +292,7 @@ systemd-tmpfiles --create --prefix /var/log/journal</programlisting>
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
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>

2
man/systemd-machine-id-commit.service.xml
View File

@ -57,7 +57,7 @@
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
as <filename>/etc/</filename> has been remounted writable and the
ID may thus be committed to disk to make it permanent.</para>
</refsect1>

4
man/systemd-machine-id-setup.xml
View File

@ -98,12 +98,12 @@
<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
<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
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

4
man/systemd-modules-load.service.xml
View File

@ -30,8 +30,8 @@
<title>Description</title>
<para><filename>systemd-modules-load.service</filename> is an early boot service that loads kernel
modules. It reads static configuration from files in <filename>/usr</filename> and
<filename>/etc</filename>, but also runtime configuration from <filename>/run</filename> and the kernel
modules. It reads static configuration from files in <filename>/usr/</filename> and
<filename>/etc/</filename>, but also runtime configuration from <filename>/run/</filename> and the kernel
command line (see below).</para>
<para>See

24
man/systemd-nspawn.xml
View File

@ -52,7 +52,7 @@
<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
<filename>/var/lib/machines/</filename>, the suggested directory to place OS container images installed on the
system.</para>
<para>In contrast to <citerefentry
@ -60,7 +60,7 @@
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
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>
@ -100,7 +100,7 @@
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
<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
@ -358,7 +358,7 @@
exists in the container image operated on, and even if <option>--volatile=state</option> is used the
hypothetical file <filename index="false">/etc/foobar</filename> is potentially writable if
<option>--bind=/etc/foobar</option> if used to mount it from outside the read-only container
<filename>/etc</filename> directory.</para>
<filename>/etc/</filename> directory.</para>
<para>The <option>--ephemeral</option> option is closely related to this setting, and provides similar
behaviour by making a temporary, ephemeral copy of the whole OS image and executing that. For further details,
@ -1269,7 +1269,7 @@
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
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
@ -1340,13 +1340,13 @@
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>The source paths may optionally be prefixed with <literal>+</literal> character. If so they are
taken relative to the image's root directory. The uppermost source path may also be specified as an
empty string, in which case a temporary directory below the host's <filename>/var/tmp/</filename> is
used. The directory is removed automatically when the container is shut down. This behaviour is
useful in order to make read-only container directories writable while the container is running. For
example, use <literal>--overlay=+/var::/var</literal> in order to automatically overlay a writable
temporary directory on a read-only <filename>/var/</filename> directory.</para>
<para>For details about overlay file systems, see <ulink
url="https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt">overlayfs.txt</ulink>. Note

8
man/systemd-remount-fs.service.xml
View File

@ -34,13 +34,13 @@
project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, or
gathered from the partition table (when
<citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
is active) to the root file system, the <filename>/usr</filename> file system, and the kernel API file
is active) to the root file system, the <filename>/usr/</filename> file system, and the kernel API file
systems. This is required so that the mount options of these file systems — which are pre-mounted by the
kernel, the initial RAM disk, container environments or system manager code — are updated to those
configured in <filename>/etc/fstab</filename> and the other sources. This service ignores normal file
systems and only changes the root file system (i.e. <filename>/</filename>), <filename>/usr</filename>,
and the virtual kernel API file systems such as <filename>/proc</filename>, <filename>/sys</filename> or
<filename>/dev</filename>. This service executes no operation if no configuration is found
systems and only changes the root file system (i.e. <filename>/</filename>), <filename>/usr/</filename>,
and the virtual kernel API file systems such as <filename>/proc/</filename>, <filename>/sys/</filename> or
<filename>/dev/</filename>. This service executes no operation if no configuration is found
(<filename>/etc/fstab</filename> does not exist or lists no entries for the mentioned file systems, or
the partition table does not contain relevant entries).</para>

2
man/systemd-sysctl.service.xml
View File

@ -51,7 +51,7 @@
<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
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>

4
man/systemd-tmpfiles.xml
View File

@ -78,8 +78,8 @@
and administrator-controlled files under <filename>/usr/share/user-tmpfiles.d/</filename>. Users may use
this to create and clean up files under their control, but the system instance performs global cleanup
and is not influenced by user configuration. Note that this means a time-based cleanup configured in the
system instance, such as the one typically configured for <filename>/tmp</filename>, will thus also
affect files created by the user instance if they are placed in <filename>/tmp</filename>, even if the
system instance, such as the one typically configured for <filename>/tmp/</filename>, will thus also
affect files created by the user instance if they are placed in <filename>/tmp/</filename>, even if the
user instance's time-based cleanup is turned off.</para>
</refsect1>

20
man/systemd-update-done.service.xml
View File

@ -18,7 +18,7 @@
<refnamediv>
<refname>systemd-update-done.service</refname>
<refname>systemd-update-done</refname>
<refpurpose>Mark <filename>/etc</filename> and <filename>/var</filename> fully updated</refpurpose>
<refpurpose>Mark <filename>/etc/</filename> and <filename>/var/</filename> fully updated</refpurpose>
</refnamediv>
<refsynopsisdiv>
@ -31,30 +31,30 @@
<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
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
<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
<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>/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>
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
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
<filename>/usr/</filename>, for example by invoking
<citerefentry project='man-pages'><refentrytitle>touch</refentrytitle><manvolnum>1</manvolnum></citerefentry>
on it.</para>

4
man/systemd-volatile-root.service.xml
View File

@ -31,8 +31,8 @@
<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
<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>

4
man/systemd.device.xml
View File

@ -49,8 +49,8 @@
<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
<para>Device units are named after the <filename>/sys/</filename>
and <filename>/dev/</filename> paths they control. Example: the
device <filename index="false">/dev/sda5</filename> is exposed in
systemd as <filename>dev-sda5.device</filename>. For details about
the escaping logic used to convert a file system path to a unit

10
man/systemd.dnssd.xml
View File

@ -42,9 +42,9 @@
<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
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
@ -55,8 +55,8 @@
<para>In addition to <filename>/etc/systemd/dnssd</filename>, drop-in <literal>.d</literal> directories
can be placed in <filename>/usr/lib/systemd/dnssd</filename> or <filename>/run/systemd/dnssd</filename>
directories. Drop-in files in <filename>/etc</filename> take precedence over those in
<filename>/run</filename> which in turn take precedence over those in <filename>/usr/lib</filename> or
directories. Drop-in files in <filename>/etc/</filename> take precedence over those in
<filename>/run/</filename> which in turn take precedence over those in <filename>/usr/lib/</filename> or
<filename>/usr/local/lib</filename>. Drop-in files under any of these directories take precedence over
the main network service file wherever located.</para>
</refsect1>

2
man/systemd.environment-generator.xml
View File

@ -65,7 +65,7 @@
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>
<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

64
man/systemd.exec.xml
View File

@ -61,10 +61,12 @@
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>Similarly, units with <varname>PrivateTmp=</varname> enabled automatically get mount
unit dependencies for all mounts required to access <filename>/tmp/</filename> and
<filename>/var/tmp/</filename>. They will also gain an automatic <varname>After=</varname> dependency
on
<citerefentry><refentrytitle>systemd-tmpfiles-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para></listitem>
<listitem><para>Units whose standard output or error output is connected to <option>journal</option> or
<option>kmsg</option> (or their combinations with console output, see below) automatically acquire
@ -273,11 +275,11 @@
<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>
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
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>
@ -1121,12 +1123,12 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
<term><varname>ProtectSystem=</varname></term>
<listitem><para>Takes a boolean argument or the special values <literal>full</literal> or
<literal>strict</literal>. If true, mounts the <filename>/usr</filename> and the boot loader
<literal>strict</literal>. If true, mounts the <filename>/usr/</filename> and the boot loader
directories (<filename>/boot</filename> and <filename>/efi</filename>) read-only for processes
invoked by this unit. If set to <literal>full</literal>, the <filename>/etc</filename> directory is
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
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
@ -1142,7 +1144,7 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
<term><varname>ProtectHome=</varname></term>
<listitem><para>Takes a boolean argument or the special values <literal>read-only</literal> or
<literal>tmpfs</literal>. If true, the directories <filename>/home</filename>,
<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
@ -1259,13 +1261,13 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
<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
runtime directories in <filename>/run/</filename> due to lack of privileges, and to make sure the runtime
directory is cleaned up automatically after use. For runtime directories that require more complex or different
configuration or lifetime guarantees, please consider using
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
<para>The directories defined by these options are always created under the standard paths used by systemd
(<filename>/var</filename>, <filename>/run</filename>, <filename>/etc</filename>, …). If the service needs
(<filename>/var/</filename>, <filename>/run/</filename>, <filename>/etc/</filename>, …). If the service needs
directories in a different location, a different mechanism has to be used to create them.</para>
<para><citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> provides
@ -1319,7 +1321,7 @@ StateDirectory=aaa/bbb ccc</programlisting>
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
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>
@ -1409,7 +1411,7 @@ StateDirectory=aaa/bbb ccc</programlisting>
<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
then the invoked processes by the unit cannot see any files or directories under <filename>/var/</filename> except for
<filename>/var/lib/systemd</filename> or its contents.</para>
<xi:include href="system-only.xml" xpointer="singular"/></listitem>
@ -1418,20 +1420,22 @@ BindReadOnlyPaths=/var/lib/systemd</programlisting>
<varlistentry>
<term><varname>PrivateTmp=</varname></term>
<listitem><para>Takes a boolean argument. If true, sets up a new file system namespace for the executed
processes and mounts private <filename>/tmp/</filename> and <filename>/var/tmp/</filename> directories inside it
that are not shared by processes outside of the namespace. This is useful to secure access to temporary files of
the process, but makes sharing between processes via <filename>/tmp</filename> or <filename>/var/tmp</filename>
impossible. If this is enabled, all temporary files created by a service in these directories will be removed
after the service is stopped. Defaults to false. It is possible to run two or more units within the same
private <filename>/tmp</filename> and <filename>/var/tmp</filename> namespace by using the
<listitem><para>Takes a boolean argument. If true, sets up a new file system namespace for the
executed processes and mounts private <filename>/tmp/</filename> and <filename>/var/tmp/</filename>
directories inside it that are not shared by processes outside of the namespace. This is useful to
secure access to temporary files of the process, but makes sharing between processes via
<filename>/tmp/</filename> or <filename>/var/tmp/</filename> impossible. If this is enabled, all
temporary files created by a service in these directories will be removed after the service is
stopped. Defaults to false. It is possible to run two or more units within the same private
<filename>/tmp/</filename> and <filename>/var/tmp/</filename> namespace by using the
<varname>JoinsNamespaceOf=</varname> directive, see
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
details. This setting is implied if <varname>DynamicUser=</varname> is set. For this setting the same
restrictions regarding mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and
related calls, see above. Enabling this setting has the side effect of adding <varname>Requires=</varname> and
<varname>After=</varname> dependencies on all mount units necessary to access <filename>/tmp</filename> and
<filename>/var/tmp</filename>. Moreover an implicitly <varname>After=</varname> ordering on
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>
@ -1445,7 +1449,7 @@ BindReadOnlyPaths=/var/lib/systemd</programlisting>
<varlistentry>
<term><varname>PrivateDevices=</varname></term>
<listitem><para>Takes a boolean argument. If true, sets up a new <filename>/dev</filename> mount for the
<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>,
@ -1458,7 +1462,7 @@ BindReadOnlyPaths=/var/lib/systemd</programlisting>
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
<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
@ -1591,7 +1595,7 @@ BindReadOnlyPaths=/var/lib/systemd</programlisting>
<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/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
@ -1652,7 +1656,7 @@ BindReadOnlyPaths=/var/lib/systemd</programlisting>
<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
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

30
man/systemd.generator.xml
View File

@ -66,10 +66,10 @@
<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
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
<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>.
@ -86,8 +86,8 @@
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>
<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
@ -125,8 +125,8 @@
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
<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>
@ -161,11 +161,11 @@
<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
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>.
including a mounted <filename>/sys/</filename>, <filename>/proc/</filename>,
<filename>/dev/</filename>, <filename>/usr/</filename>.
</para>
</listitem>
@ -208,7 +208,7 @@
<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
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>
@ -226,8 +226,8 @@
<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>
(mostly) means that stuff from <filename>/etc/</filename> should override
stuff from <filename>/usr/</filename>.</para>
</listitem>
<listitem>
@ -262,7 +262,7 @@
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>
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

6
man/systemd.journal-fields.xml
View File

@ -414,21 +414,21 @@
<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>
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>
<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
in <filename>/dev/</filename>. This field is frequently set
more than once per entry.</para>
</listitem>
</varlistentry>

6
man/systemd.link.xml
View File

@ -42,9 +42,9 @@
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
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

8
man/systemd.mount.xml
View File

@ -430,13 +430,13 @@
<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
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>
<filename>/etc/</filename> will always take precedence over
configuration in <filename>/usr/</filename>.</para>
</refsect1>
<refsect1>

12
man/systemd.netdev.xml
View File

@ -43,9 +43,9 @@
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
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>
@ -59,10 +59,10 @@
<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
<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
<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>

10
man/systemd.network.xml
View File

@ -43,9 +43,9 @@
<filename>/run/systemd/network</filename> and the local administration network directory
<filename>/etc/systemd/network</filename>. All configuration files are collectively sorted and processed
in lexical order, regardless of the directories in which they live. However, files with identical
filenames replace each other. Files in <filename>/etc</filename> have the highest priority, files in
<filename>/run</filename> take precedence over files with the same name under
<filename>/usr</filename>. This can be used to override a system-supplied configuration file with a local
filenames replace each other. Files in <filename>/etc/</filename> have the highest priority, files in
<filename>/run/</filename> take precedence over files with the same name under
<filename>/usr/</filename>. This can be used to override a system-supplied configuration file with a local
file if needed. As a special case, an empty file (file size 0) or symlink with the same name pointing to
<filename>/dev/null</filename> disables the configuration file entirely (it is "masked").</para>
@ -58,8 +58,8 @@
<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
<filename>/etc/</filename> take precedence over those in <filename>/run/</filename> which in turn
take precedence over those in <filename>/usr/lib/</filename>. Drop-in files under any of these
directories take precedence over the main network file wherever located.</para>
<para>Note that an interface without any static IPv6 addresses configured, and neither DHCPv6

2
man/systemd.offline-updates.xml
View File

@ -44,7 +44,7 @@
created that points to <filename index="false">/var/lib/system-update</filename> (or
wherever the directory with the upgrade files is located) and the system is rebooted. This
symlink is in the root directory, since we need to check for it very early at boot, at a
time where <filename>/var</filename> is not available yet.</para>
time where <filename>/var/</filename> is not available yet.</para>
</listitem>
<listitem>

2
man/systemd.service.xml
View File

@ -1035,7 +1035,7 @@
<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
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

4
man/systemd.socket.xml
View File

@ -267,8 +267,8 @@
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>
<filename>/proc/</filename> and
<filename>/sys/</filename>.</para></listitem>
</varlistentry>
<varlistentry>

4
man/systemd.special.xml
View File

@ -132,8 +132,8 @@
<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,
<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.

40
man/systemd.unit.xml
View File

@ -213,9 +213,9 @@
<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
<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>
@ -803,9 +803,9 @@
<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
<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
joined. Note that this setting only has an effect if
<varname>PrivateNetwork=</varname>/<varname>NetworkNamespacePath=</varname> and/or
<varname>PrivateTmp=</varname> is enabled for both the unit that joins the namespace and the unit
whose namespace is joined.</para></listitem>
@ -1287,13 +1287,13 @@
<varlistentry>
<term><varname>ConditionNeedsUpdate=</varname></term>
<listitem><para>Takes one of <filename>/var</filename> or <filename>/etc</filename> as argument,
<listitem><para>Takes one of <filename>/var/</filename> or <filename>/etc/</filename> as argument,
possibly prefixed with a <literal>!</literal> (to invert the condition). This condition may be
used to conditionalize units on whether the specified directory requires an update because
<filename>/usr</filename>'s modification time is newer than the stamp file
<filename>/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
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
@ -1312,9 +1312,9 @@
<term><varname>ConditionFirstBoot=</varname></term>
<listitem><para>Takes a boolean argument. This condition may be used to conditionalize units on
whether the system is booting up 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
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>If the <varname>systemd.condition-first-boot=</varname> option is specified on the kernel
@ -1771,7 +1771,7 @@
<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>
<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>
@ -1857,13 +1857,9 @@ Note that this setting is <emphasis>not</emphasis> influenced by the <varname>Us
<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>
<entry>This is either <filename>/run/</filename> (for the system manager) or the path <literal>$XDG_RUNTIME_DIR</literal> resolves to (for user managers).</entry>
</row>
<xi:include href="standard-specifiers.xml" xpointer="T"/>
<row>
<entry><literal>%g</literal></entry>
<entry>User group</entry>
@ -1889,11 +1885,7 @@ Note that this setting is <emphasis>not</emphasis> influenced by the <varname>Us
Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry>
</row>
<xi:include href="standard-specifiers.xml" xpointer="v"/>
<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>
<xi:include href="standard-specifiers.xml" xpointer="V"/>
<xi:include href="standard-specifiers.xml" xpointer="w"/>
<xi:include href="standard-specifiers.xml" xpointer="W"/>
<xi:include href="standard-specifiers.xml" xpointer="percent"/>

2
man/systemd.xml
View File

@ -264,7 +264,7 @@
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>
<filename>/sys/</filename> or <filename>/proc/</filename>.</para>
<para>For more information about the concepts and
ideas behind systemd, please refer to the

12
man/sysusers.d.xml
View File

@ -260,17 +260,9 @@ r - 500-900
<xi:include href="standard-specifiers.xml" xpointer="l"/>
<xi:include href="standard-specifiers.xml" xpointer="m"/>
<xi:include href="standard-specifiers.xml" xpointer="o"/>
<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>
<xi:include href="standard-specifiers.xml" xpointer="T"/>
<xi:include href="standard-specifiers.xml" xpointer="v"/>
<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>
<xi:include href="standard-specifiers.xml" xpointer="V"/>
<xi:include href="standard-specifiers.xml" xpointer="w"/>
<xi:include href="standard-specifiers.xml" xpointer="W"/>
<xi:include href="standard-specifiers.xml" xpointer="percent"/>

30
man/tmpfiles.d.xml
View File

@ -83,10 +83,10 @@ A+ /path-or-glob/to/append/acls/recursively - - - - POSIX
<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>
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
@ -94,7 +94,7 @@ A+ /path-or-glob/to/append/acls/recursively - - - - POSIX
the description of <filename>systemd-tmpfiles-setup.service</filename>,
<filename>systemd-tmpfiles-clean.service</filename>, and associated units.</para>
<para>System daemons frequently require private runtime directories below <filename>/run</filename> to
<para>System daemons frequently require private runtime directories below <filename>/run/</filename> to
store communication sockets and similar. For these, it is better to use
<varname>RuntimeDirectory=</varname> in their unit files (see
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
@ -258,11 +258,11 @@ L /tmp/foobar - - - - /dev/null</programlisting>
<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
<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>
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.
@ -661,13 +661,9 @@ w- /proc/sys/vm/swappiness - - - - 10</programlisting></para>
<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>
<entry>In <option>--user</option> mode, this is the same <varname>$XDG_RUNTIME_DIR</varname>, and <filename>/run/</filename> otherwise.</entry>
</row>
<xi:include href="standard-specifiers.xml" xpointer="T"/>
<row>
<entry><literal>%g</literal></entry>
<entry>User group</entry>
@ -689,11 +685,7 @@ w- /proc/sys/vm/swappiness - - - - 10</programlisting></para>
<entry>This is the numeric UID of the user running the command. In case of the system instance this resolves to <constant>0</constant>.</entry>
</row>
<xi:include href="standard-specifiers.xml" xpointer="v"/>
<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>
<xi:include href="standard-specifiers.xml" xpointer="V"/>
<xi:include href="standard-specifiers.xml" xpointer="w"/>
<xi:include href="standard-specifiers.xml" xpointer="W"/>
<xi:include href="standard-specifiers.xml" xpointer="percent"/>

12
man/udev.xml
View File

@ -25,7 +25,7 @@
<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>
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
@ -50,11 +50,11 @@
volatile runtime directory <filename>/run/udev/rules.d</filename> and the local administration
directory <filename>/etc/udev/rules.d</filename>. All rules files are collectively sorted and
processed in lexical order, regardless of the directories in which they live. However, files with
identical filenames replace each other. Files in <filename>/etc</filename> have the highest priority,
files in <filename>/run</filename> take precedence over files with the same name under
<filename>/usr</filename>. This can be used to override a system-supplied rules file with a local
file if needed; a symlink in <filename>/etc</filename> with the same name as a rules file in
<filename>/usr/lib</filename>, pointing to <filename>/dev/null</filename>, disables the rules file
identical filenames replace each other. Files in <filename>/etc/</filename> have the highest priority,
files in <filename>/run/</filename> take precedence over files with the same name under
<filename>/usr/</filename>. This can be used to override a system-supplied rules file with a local
file if needed; a symlink in <filename>/etc/</filename> with the same name as a rules file in
<filename>/usr/lib/</filename>, pointing to <filename>/dev/null</filename>, disables the rules file
entirely. Rule files must have the extension <filename>.rules</filename>; other extensions are
ignored.</para>

4
man/udev_device_new_from_syspath.xml
View File

@ -100,8 +100,8 @@
<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>,
<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>

10
man/udevadm.xml
View File

@ -102,8 +102,8 @@
<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
<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>
@ -114,7 +114,7 @@
<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
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>
@ -297,7 +297,7 @@
<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
<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>
@ -343,7 +343,7 @@
<para>In addition, optional positional arguments can be used
to specify device names or sys paths. They must start with
<filename>/dev</filename> or <filename>/sys</filename>
<filename>/dev/</filename> or <filename>/sys/</filename>
respectively.</para>
</refsect2>