mirror of
https://github.com/systemd/systemd.git
synced 2024-11-27 04:03:36 +08:00
man: use trailing slash on directories in more places
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
parent
7ec2f5e00c
commit
3b1211574b
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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>
|
||||
@ -1286,13 +1286,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
|
||||
@ -1311,9 +1311,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
|
||||
@ -1770,7 +1770,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>
|
||||
@ -1856,7 +1856,7 @@ 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>
|
||||
<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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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,7 +661,7 @@ 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>
|
||||
<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>
|
||||
|
||||
12
man/udev.xml
12
man/udev.xml
@ -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>
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user