For #17177.
<title>Setup environment to allow access to a program installed in
<filename index="false">/opt/foo</filename></title>
- <para><filename>/etc/environment.d/60-foo.conf</filename>:
+ <para><filename index="false">/etc/environment.d/60-foo.conf</filename>:
</para>
<programlisting>
FOO_DEBUG=force-software-gl,log-verbose
<listitem><para>Takes a path to the resume device. Both
persistent block device paths like
- <filename>/dev/disk/by-foo/bar</filename> and
+ <filename index="false">/dev/disk/by-foo/bar</filename> and
<citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>-style
specifiers like <literal>FOO=bar</literal> are
supported.</para></listitem>
<para>In order to migrate a home directory from a host <literal>foobar</literal> to another host
<literal>quux</literal> it is hence sufficient to copy
<filename>/var/lib/systemd/home/local.public</filename> from the host <literal>foobar</literal> to
- <literal>quux</literal>, maybe calling the file on the destination
- <filename>/var/lib/systemd/home/foobar.public</filename>, reflecting the origin of the key. If the user
- record should be modifiable on <literal>quux</literal> the pair
+ <literal>quux</literal>, maybe calling the file on the destination <filename
+ index="false">/var/lib/systemd/home/foobar.public</filename>, reflecting the origin of the key. If the
+ user record should be modifiable on <literal>quux</literal> the pair
<filename>/var/lib/systemd/home/local.public</filename> and
<filename>/var/lib/systemd/home/local.private</filename> need to be copied from <literal>foobar</literal>
to <literal>quux</literal>, and placed under the identical paths there, as currently only a single
terminated. When the mode parameter is specified as <option>no</option> (the default), the whole OS tree is
made available writable (unless <option>--read-only</option> is specified, see above).</para>
- <para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system (or
- <filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the hierarchy are
- unaffected — regardless if they are established automatically (e.g. the EFI system partition that might be
- mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or explicitly (e.g. through an additional
- command line option such as <option>--bind=</option>, see below). This means, even if
- <option>--volatile=overlay</option> is used changes to <filename>/efi/</filename> or
- <filename>/boot/</filename> are prohibited in case such a partition exists in the container image operated on,
- and even if <option>--volatile=state</option> is used the hypothetical file <filename>/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>
+ <para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system
+ (or <filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the
+ hierarchy are unaffected — regardless if they are established automatically (e.g. the EFI system
+ partition that might be mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or
+ explicitly (e.g. through an additional command line option such as <option>--bind=</option>, see
+ below). This means, even if <option>--volatile=overlay</option> is used changes to
+ <filename>/efi/</filename> or <filename>/boot/</filename> are prohibited in case such a partition
+ 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>
<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,
<para>Example: if a system service unit has the following,
<programlisting>RuntimeDirectory=foo/bar baz</programlisting>
- the service manager creates <filename>/run/foo</filename> (if it does not exist),
+ the service manager creates <filename index='false'>/run/foo</filename> (if it does not exist),
<filename index='false'>/run/foo/bar</filename>, and <filename index='false'>/run/baz</filename>. The
directories <filename index='false'>/run/foo/bar</filename> and
<title>Simple service</title>
<para>The following unit file creates a service that will
- execute <filename>/usr/sbin/foo-daemon</filename>. Since no
+ execute <filename index="false">/usr/sbin/foo-daemon</filename>. Since no
<varname>Type=</varname> is specified, the default
<varname>Type=</varname><option>simple</option> will be assumed.
systemd will assume the unit to be started immediately after the
pulled in via a <option>Wants=</option> dependency of the storage daemon and thus generally not be
part of any transaction unless a storage daemon is used. The instance name for instances of this
template unit must be a properly escaped block device node path, e.g.
- <filename>blockdev@dev-mapper-foobar.target</filename> for the storage device
- <filename>/dev/mapper/foobar</filename>.</para></listitem>
+ <filename index="false">blockdev@dev-mapper-foobar.target</filename> for the storage device
+ <filename index="false">/dev/mapper/foobar</filename>.</para></listitem>
</varlistentry>
<varlistentry>
<term><filename>cryptsetup-pre.target</filename></term>
<para>When the input qualifies as absolute file system path, this algorithm is extended slightly: the path to the
root directory <literal>/</literal> is encoded as single dash <literal>-</literal>. In addition, any leading,
trailing or duplicate <literal>/</literal> characters are removed from the string before transformation. Example:
- <filename>/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
+ <filename index="false">/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
<para>This escaping is fully reversible, as long as it is known whether the escaped string was a path (the
unescaping results are different for paths and non-path strings). The
<para>After running <command>systemctl enable</command>, a
symlink
- <filename>/etc/systemd/system/multi-user.target.wants/foo.service</filename>
+ <filename index="false">/etc/systemd/system/multi-user.target.wants/foo.service</filename>
linking to the actual unit will be created. It tells systemd to
pull in the unit when starting
<filename>multi-user.target</filename>. The inverse
projects / thirdparty / systemd.git / commitdiff
