mirror of
https://github.com/systemd/systemd.git
synced 2025-01-21 07:53:53 +08:00
man: similar → similarly
Something *is* similar Something *works* similarly Something does something, similarly to how something else does something See https://sites.ulethbridge.ca/roussel/2017/11/29/similar-and-similarly-are-they-similar/ for a clear explanation.
This commit is contained in:
parent
e3a4724db2
commit
15102ced42
@ -248,11 +248,11 @@
|
||||
<varlistentry>
|
||||
<term><option>--image=<replaceable>image</replaceable></option></term>
|
||||
|
||||
<listitem><para>Takes a path to a disk image file or block device node. If specified all operations
|
||||
are applied to file system in the indicated disk image. This is similar to <option>--root=</option>
|
||||
but operates on file systems stored in disk images or block devices. The disk image should either
|
||||
contain just a file system or a set of file systems within a GPT partition table, following the
|
||||
<ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions
|
||||
<listitem><para>Takes a path to a disk image file or block device node. If specified, all operations
|
||||
are applied to file system in the indicated disk image. This option is similar to
|
||||
<option>--root=</option>, but operates on file systems stored in disk images or block devices. The
|
||||
disk image should either contain just a file system or a set of file systems within a GPT partition
|
||||
table, following the <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions
|
||||
Specification</ulink>. For further information on supported disk images, see
|
||||
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
||||
switch of the same name.</para></listitem>
|
||||
@ -289,7 +289,7 @@
|
||||
Specification Type #2 entries should be placed in the directory <literal>$(bootctl
|
||||
-x)/EFI/Linux/</literal>.</para>
|
||||
|
||||
<para>Note that this option (similar to the <option>--print-booth-path</option> option mentioned
|
||||
<para>Note that this option (similarly to the <option>--print-booth-path</option> option mentioned
|
||||
above), is available independently from the boot loader used, i.e. also without
|
||||
<command>systemd-boot</command> being installed.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -342,9 +342,9 @@
|
||||
|
||||
<para>If set to <option>os-id</option> the entries are named after the OS ID of the running system,
|
||||
i.e. the <varname>ID=</varname> field of
|
||||
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
(e.g. <literal>fedora</literal>). Similar, if set to <option>os-image-id</option> the entries are
|
||||
named after the OS image ID of the running system, i.e. the <varname>IMAGE_ID=</varname> field of
|
||||
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> (e.g.
|
||||
<literal>fedora</literal>). Similarly, if set to <option>os-image-id</option> the entries are named
|
||||
after the OS image ID of the running system, i.e. the <varname>IMAGE_ID=</varname> field of
|
||||
<filename>os-release</filename> (e.g. <literal>vendorx-cashier-system</literal>).</para>
|
||||
|
||||
<para>If set to <option>auto</option> (the default), the <filename>/etc/kernel/entry-token</filename>
|
||||
|
@ -161,9 +161,9 @@
|
||||
<term><option>--image=<replaceable>IMAGE</replaceable></option></term>
|
||||
|
||||
<listitem><para>Takes a path to a disk image file or block device node. If specified,
|
||||
<command>journalctl</command> will operate on the file system in the indicated disk image. This is
|
||||
similar to <option>--root=</option> but operates on file systems stored in disk images or block
|
||||
devices, thus providing an easy way to extract log data from disk images. The disk image should
|
||||
<command>journalctl</command> will operate on the file system in the indicated disk image. This
|
||||
option is similar to <option>--root=</option>, but operates on file systems stored in disk images or
|
||||
block devices, thus providing an easy way to extract log data from disk images. The disk image should
|
||||
either contain just a file system or a set of file systems within a GPT partition table, following
|
||||
the <ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions
|
||||
Specification</ulink>. For further information on supported disk images, see
|
||||
@ -493,9 +493,9 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><option>with-unit</option></term>
|
||||
<listitem><para>similar to short-full, but prefixes the unit and user unit names instead of the
|
||||
traditional syslog identifier. Useful when using templated instances, as it will include the
|
||||
arguments in the unit names.</para></listitem>
|
||||
<listitem><para>similar to <option>short-full</option>, but prefixes the unit and user unit names
|
||||
instead of the traditional syslog identifier. Useful when using templated instances, as it will
|
||||
include the arguments in the unit names.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist></listitem>
|
||||
</varlistentry>
|
||||
@ -765,11 +765,11 @@
|
||||
<varlistentry>
|
||||
<term><option>--smart-relinquish-var</option></term>
|
||||
|
||||
<listitem><para>Similar to <option>--relinquish-var</option> but executes no operation if the root
|
||||
file system and <filename>/var/lib/journal/</filename> reside on the same mount point. This
|
||||
operation is used during system shutdown in order to make the journal daemon stop writing data to
|
||||
<filename>/var/log/journal/</filename> in case that directory is located on a mount point that
|
||||
needs to be unmounted.</para></listitem>
|
||||
<listitem><para>Similar to <option>--relinquish-var</option>, but executes no operation if the root
|
||||
file system and <filename>/var/lib/journal/</filename> reside on the same mount point. This operation
|
||||
is used during system shutdown in order to make the journal daemon stop writing data to
|
||||
<filename>/var/log/journal/</filename> in case that directory is located on a mount point that needs
|
||||
to be unmounted.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
@ -192,7 +192,7 @@
|
||||
the machine name is specified as the empty string, or the
|
||||
special machine name <literal>.host</literal> (see below) is
|
||||
specified, the connection is made to the local host
|
||||
instead. This works similar to <command>login</command> but
|
||||
instead. This works similarly to <command>login</command>, but
|
||||
immediately invokes a user process. This command runs the
|
||||
specified executable with the specified arguments, or the
|
||||
default shell for the user if none is specified, or
|
||||
@ -205,40 +205,35 @@
|
||||
<para>Note that <command>machinectl shell</command> does not propagate the exit code/status of the invoked
|
||||
shell process. Use <command>systemd-run</command> instead if that information is required (see below).</para>
|
||||
|
||||
<para>When using the <command>shell</command> command without
|
||||
arguments, (thus invoking the executed shell or command on the
|
||||
local host), it is in many ways similar to a <citerefentry
|
||||
project='die-net'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
session, but, unlike <command>su</command>, completely isolates
|
||||
the new session from the originating session, so that it
|
||||
shares no process or session properties, and is in a clean and
|
||||
well-defined state. It will be tracked in a new utmp, login,
|
||||
audit, security and keyring session, and will not inherit any
|
||||
environment variables or resource limits, among other
|
||||
properties.</para>
|
||||
<para>Using the <command>shell</command> command without arguments (thus invoking the executed shell
|
||||
or command on the local host), is in many ways similar to a <citerefentry
|
||||
project='die-net'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry> session,
|
||||
but, unlike <command>su</command>, completely isolates the new session from the originating session,
|
||||
so that it shares no process or session properties and is in a clean well-defined state. It will be
|
||||
tracked in a new utmp, login, audit, security, and keyring sessions, and will not inherit any
|
||||
environment variables or resource limits, among other properties.</para>
|
||||
|
||||
<para>Note that <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
with its <option>--machine=</option> switch may be used in place of the <command>machinectl shell</command>
|
||||
command, and allows non-interactive operation, more detailed and low-level configuration of the invoked unit,
|
||||
as well as access to runtime and exit code/status information of the invoked shell process. In particular, use
|
||||
<command>systemd-run</command>'s <option>--wait</option> switch to propagate exit status information of the
|
||||
invoked process. Use <command>systemd-run</command>'s <option>--pty</option> switch for acquiring an
|
||||
interactive shell, similar to <command>machinectl shell</command>. In general, <command>systemd-run</command>
|
||||
is preferable for scripting purposes. However, note that <command>systemd-run</command> might require higher
|
||||
privileges than <command>machinectl shell</command>.</para></listitem>
|
||||
<para>Note that
|
||||
<citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry> with
|
||||
its <option>--machine=</option> switch may be used in place of the <command>machinectl
|
||||
shell</command> command, and allows non-interactive operation, more detailed and low-level
|
||||
configuration of the invoked unit, as well as access to runtime and exit code/status information of
|
||||
the invoked shell process. In particular, use <command>systemd-run</command>'s
|
||||
<option>--wait</option> switch to propagate exit status information of the invoked process. Use
|
||||
<command>systemd-run</command>'s <option>--pty</option> switch to acquire an interactive shell,
|
||||
similarly to <command>machinectl shell</command>. In general, <command>systemd-run</command> is
|
||||
preferable for scripting purposes. However, note that <command>systemd-run</command> might require
|
||||
higher privileges than <command>machinectl shell</command>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><command>enable</command> <replaceable>NAME</replaceable>…</term>
|
||||
<term><command>disable</command> <replaceable>NAME</replaceable>…</term>
|
||||
|
||||
<listitem><para>Enable or disable a container as a system
|
||||
service to start at system boot, using
|
||||
<listitem><para>Enable or disable a container as a system service to start at system boot, using
|
||||
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
||||
This enables or disables
|
||||
<filename>systemd-nspawn@.service</filename>, instantiated for
|
||||
the specified machine name, similar to the effect of
|
||||
<command>systemctl enable</command> or <command>systemctl
|
||||
This enables or disables <filename>systemd-nspawn@.service</filename>, instantiated for the specified
|
||||
machine name, similarly to the effect of <command>systemctl enable</command> or <command>systemctl
|
||||
disable</command> on the service name.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -544,11 +539,9 @@
|
||||
machine name. To omit creation of the local, writable copy
|
||||
pass <literal>-</literal> as local machine name.</para>
|
||||
|
||||
<para>Similar to the behavior of <command>pull-tar</command>,
|
||||
the read-only image is prefixed with
|
||||
<filename>.raw-</filename>, and thus not shown by
|
||||
<command>list-images</command>, unless <option>--all</option>
|
||||
is passed.</para>
|
||||
<para>Similarly to the behavior of <command>pull-tar</command>, the read-only image is prefixed with
|
||||
<filename>.raw-</filename>, and thus not shown by <command>list-images</command>, unless
|
||||
<option>--all</option> is passed.</para>
|
||||
|
||||
<para>Note that pressing C-c during execution of this command
|
||||
will not abort the download. Use
|
||||
@ -586,9 +579,9 @@
|
||||
<term><command>import-fs</command> <replaceable>DIRECTORY</replaceable> [<replaceable>NAME</replaceable>]</term>
|
||||
|
||||
<listitem><para>Imports a container image stored in a local directory into
|
||||
<filename>/var/lib/machines/</filename>, operates similar to <command>import-tar</command> or
|
||||
<command>import-raw</command>, but the first argument is the source directory. If supported, this command will
|
||||
create btrfs snapshot or subvolume for the new image.</para></listitem>
|
||||
<filename>/var/lib/machines/</filename>, operates similarly to <command>import-tar</command> or
|
||||
<command>import-raw</command>, but the first argument is the source directory. If supported, this
|
||||
command will create a btrfs snapshot or subvolume for the new image.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
@ -183,14 +183,14 @@ node /org/freedesktop/import1 {
|
||||
specified file descriptor will be a tar file in case of <function>ExportTar()</function> or a raw disk
|
||||
image in case of <function>ExportRaw()</function>. Note that currently raw disk images may not be
|
||||
exported as tar files, and vice versa. This restriction might be lifted eventually. The method
|
||||
returns a transfer identifier and object path for cancelling or tracking the export operation, similar
|
||||
returns a transfer identifier and object path for cancelling or tracking the export operation, similarly
|
||||
to <function>ImportTar()</function> or <function>ImportRaw()</function> as described above.</para>
|
||||
|
||||
<para><function>PullTar()</function> and <function>PullRaw()</function> may be used to download, verify
|
||||
and import a system image from a URL. They take an URL argument which should point to a tar or
|
||||
raw file on the <literal>http://</literal> or <literal>https://</literal> protocols, possibly
|
||||
compressed with xz, bzip2 or gzip. The second argument is a local name for the image. It should be
|
||||
suitable as a hostname, similar to the matching argument of the <function>ImportTar()</function> and
|
||||
suitable as a hostname, similarly to the matching argument of the <function>ImportTar()</function> and
|
||||
<function>ImportRaw()</function> methods above. The third argument indicates the verification mode for
|
||||
the image. It may be one of <literal>no</literal>, <literal>checksum</literal>,
|
||||
<literal>signature</literal>. <literal>no</literal> turns off any kind of verification of the image;
|
||||
|
@ -873,8 +873,9 @@ node /org/freedesktop/login1/seat/seat0 {
|
||||
<refsect2>
|
||||
<title>Methods</title>
|
||||
|
||||
<para><function>Terminate()</function> and <function>ActivateSession()</function> work similar to
|
||||
TerminateSeat(), ActivationSessionOnSeat() on the Manager object.</para>
|
||||
<para><function>Terminate()</function> and <function>ActivateSession()</function> work similarly to
|
||||
<function>TerminateSeat()</function> and <function>ActivationSessionOnSeat()</function> on the Manager
|
||||
object.</para>
|
||||
|
||||
<para><function>SwitchTo()</function> switches to the session on the virtual terminal
|
||||
<varname>vtnr</varname>. <function>SwitchToNext()</function> and
|
||||
@ -907,8 +908,8 @@ node /org/freedesktop/login1/seat/seat0 {
|
||||
encoded in a structure consisting of the ID and the object path.</para>
|
||||
|
||||
<para>The <varname>IdleHint</varname>, <varname>IdleSinceHint</varname>, and
|
||||
<varname>IdleSinceHintMonotonic</varname> properties encode the idle state, similar to the ones exposed
|
||||
on the <interfacename>Manager</interfacename> object, but specific for this seat.</para>
|
||||
<varname>IdleSinceHintMonotonic</varname> properties encode the idle state, similarly to the ones
|
||||
exposed on the <interfacename>Manager</interfacename> object, but specific for this seat.</para>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
||||
@ -1000,7 +1001,7 @@ node /org/freedesktop/login1/user/_1000 {
|
||||
<refsect2>
|
||||
<title>Methods</title>
|
||||
|
||||
<para><function>Terminate()</function> and <function>Kill()</function> work similar to the
|
||||
<para><function>Terminate()</function> and <function>Kill()</function> work similarly to the
|
||||
<function>TerminateUser()</function> and <function>KillUser()</function> methods on the manager
|
||||
object.</para>
|
||||
</refsect2>
|
||||
@ -1050,8 +1051,8 @@ node /org/freedesktop/login1/user/_1000 {
|
||||
user. Each structure consists of the ID and object path.</para>
|
||||
|
||||
<para>The <varname>IdleHint</varname>, <varname>IdleSinceHint</varname>, and
|
||||
<varname>IdleSinceHintMonotonic</varname> properties encode the idle hint state of the user, similar to
|
||||
the <interfacename>Manager</interfacename>'s properties, but specific for this user.</para>
|
||||
<varname>IdleSinceHintMonotonic</varname> properties encode the idle hint state of the user, similarly
|
||||
to the <interfacename>Manager</interfacename>'s properties, but specific for this user.</para>
|
||||
|
||||
<para>The <varname>Linger</varname> property shows whether lingering is enabled for this user.</para>
|
||||
</refsect2>
|
||||
|
@ -399,7 +399,7 @@
|
||||
<varlistentry>
|
||||
<term><varname>PaddingWeight=</varname></term>
|
||||
|
||||
<listitem><para>Similar to <varname>Weight=</varname> but sets a weight for the free space after the
|
||||
<listitem><para>Similar to <varname>Weight=</varname>, but sets a weight for the free space after the
|
||||
partition (the "padding"). When distributing available space the weights of all partitions and all
|
||||
defined padding is summed, and then each partition and padding gets the fraction defined by its
|
||||
weight. Defaults to 0, i.e. by default no padding is applied.</para>
|
||||
@ -493,9 +493,9 @@
|
||||
|
||||
<para>This option has no effect if the partition already exists.</para>
|
||||
|
||||
<para>Similar to the behaviour of <varname>CopyBlocks=</varname> the file system is formatted before
|
||||
the partition is created, ensuring that the partition only ever exists with a fully initialized
|
||||
file system.</para>
|
||||
<para>Similarly to the behaviour of <varname>CopyBlocks=</varname>, the file system is formatted
|
||||
before the partition is created, ensuring that the partition only ever exists with a fully
|
||||
initialized file system.</para>
|
||||
|
||||
<para>This option cannot be combined with <varname>CopyBlocks=</varname>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
@ -99,7 +99,7 @@
|
||||
synchronously when connected to a bus broker, i.e. the call sends a control message requested the match to be added
|
||||
to the broker and waits until the broker confirms the match has been installed successfully.</para>
|
||||
|
||||
<para><function>sd_bus_add_match_async()</function> operates very similar to
|
||||
<para><function>sd_bus_add_match_async()</function> operates very similarly to
|
||||
<function>sd_bus_add_match()</function>, however it installs the match asynchronously, in a non-blocking
|
||||
fashion: a request is sent to the broker, but the call does not wait for a response. The
|
||||
<parameter>install_callback</parameter> function is called when the response is later received, with the response
|
||||
|
@ -39,7 +39,7 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para><function>sd_bus_enqueue_for_read()</function> may be used to re-enqueue an incoming bus message on
|
||||
the local read queue, so that it is processed and dispatched locally again, similar to how an incoming
|
||||
the local read queue, so that it is processed and dispatched locally again, similarly to how an incoming
|
||||
message from the peer is processed. Takes a bus connection object and the message to enqueue. A reference
|
||||
is taken of the message and the caller's reference thus remains in possession of the caller. The message
|
||||
is enqueued at the end of the queue, thus will be dispatched after all other already queued messages are
|
||||
|
@ -229,12 +229,10 @@
|
||||
<function>sd_peer_get_machine_name()</function>,
|
||||
<function>sd_peer_get_slice()</function>,
|
||||
<function>sd_peer_get_user_slice()</function> and
|
||||
<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>,
|
||||
and hence are not suitable for authorization purposes, as they are
|
||||
subject to races.</para>
|
||||
<function>sd_peer_get_cgroup()</function> calls operate similarly to their PID counterparts, but accept a
|
||||
connected <constant>AF_UNIX</constant> socket and retrieve information about the connected peer process.
|
||||
Note 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>
|
||||
|
||||
<refsect1>
|
||||
|
@ -215,7 +215,7 @@ multi-user.target reached after 47.820s in userspace
|
||||
<replaceable>UNIT</replaceable>s or for the default target otherwise). The time after the unit is
|
||||
active or started is printed after the "@" character. The time the unit takes to start is printed after
|
||||
the "+" character. Note that the output might be misleading as the initialization of services might
|
||||
depend on socket activation and because of the parallel execution of units. Also, similar to the
|
||||
depend on socket activation and because of the parallel execution of units. Also, similarly to the
|
||||
<command>blame</command> command, this only takes into account the time units spent in
|
||||
<literal>activating</literal> state, and hence does not cover units that never went through an
|
||||
<literal>activating</literal> state (such as device units that transition directly from
|
||||
|
@ -218,9 +218,9 @@
|
||||
<varlistentry>
|
||||
<term><option>-n</option></term>
|
||||
|
||||
<listitem><para>By default, when writing the acquired password to standard output it is suffixed by a
|
||||
newline character. This may be turned off with the <option>-n</option> switch, similar to the switch
|
||||
of the same name of the <citerefentry
|
||||
<listitem><para>By default, when the acquired password is written to standard output it is suffixed
|
||||
by a newline character. This may be turned off with the <option>-n</option> switch, similarly to the
|
||||
switch of the same name of the <citerefentry
|
||||
project='man-pages'><refentrytitle>echo</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
command.</para></listitem>
|
||||
</varlistentry>
|
||||
|
@ -115,12 +115,10 @@
|
||||
<varlistentry>
|
||||
<term><option>--level-prefix=</option></term>
|
||||
|
||||
<listitem><para>Controls whether lines read are parsed for
|
||||
syslog priority level prefixes. If enabled (the default), a
|
||||
line prefixed with a priority prefix such as
|
||||
<literal><5></literal> is logged at priority 5
|
||||
(<literal>notice</literal>), and similar for the other
|
||||
priority levels. Takes a boolean argument.</para></listitem>
|
||||
<listitem><para>Controls whether lines read are parsed for syslog priority level prefixes. If enabled
|
||||
(the default), a line prefixed with a priority prefix such as <literal><5></literal> is logged
|
||||
at priority 5 (<literal>notice</literal>), and similarly for the other priority levels. Takes a
|
||||
boolean argument.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
@ -156,10 +154,9 @@
|
||||
<programlisting># ls | systemd-cat</programlisting>
|
||||
</example>
|
||||
|
||||
<para>Even though the two examples have very similar effects the
|
||||
first is preferable since only one process is running at a time,
|
||||
and both stdout and stderr are captured while in the second
|
||||
example, only stdout is captured.</para>
|
||||
<para>Even though the two examples have very similar effects, the first is preferable, since only one
|
||||
process is running at a time and both stdout and stderr are captured, while in the second example, only
|
||||
stdout is captured.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
@ -37,7 +37,7 @@
|
||||
|
||||
<para>If the <option>systemd.mask=</option> or <option>rd.systemd.mask=</option>
|
||||
option is specified and followed by a unit name, this unit is
|
||||
masked for the runtime (i.e. for this session - from boot to shutdown), similar to the effect of
|
||||
masked for the runtime (i.e. for this session — from boot to shutdown), similarly to the effect of
|
||||
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
||||
<command>mask</command> command. This is useful to boot with
|
||||
certain units removed from the initial boot transaction for
|
||||
|
@ -660,7 +660,7 @@
|
||||
<listitem><para>Set a unit property on the scope unit to register for the machine. This applies only if the
|
||||
machine is run in its own scope unit, i.e. if <option>--keep-unit</option> isn't used. Takes unit property
|
||||
assignments in the same format as <command>systemctl set-property</command>. This is useful to set memory
|
||||
limits and similar for container.</para>
|
||||
limits and similar for the container.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -737,9 +737,9 @@
|
||||
the UID/GID range is automatically chosen. As first step, the file owner UID/GID of the root
|
||||
directory of the container's directory tree is read, and it is checked that no other container is
|
||||
currently using it. If this check is successful, the UID/GID range determined this way is used,
|
||||
similar to the behavior if <literal>yes</literal> is specified. If the check is not successful (and
|
||||
thus the UID/GID range indicated in the root directory's file owner is already used elsewhere) a
|
||||
new – currently unused – UID/GID range of 65536 UIDs/GIDs is randomly chosen between the host
|
||||
similarly to the behavior if <literal>yes</literal> is specified. If the check is not successful
|
||||
(and thus the UID/GID range indicated in the root directory's file owner is already used elsewhere)
|
||||
a new – currently unused – UID/GID range of 65536 UIDs/GIDs is randomly chosen between the host
|
||||
UID/GIDs of 524288 and 1878982656, always starting at a multiple of 65536, and, if possible,
|
||||
consistently hashed from the machine name. This setting implies
|
||||
<option>--private-users-ownership=auto</option> (see below), which possibly has the effect that the
|
||||
@ -1235,8 +1235,8 @@ After=sys-subsystem-net-devices-ens1.device</programlisting>
|
||||
|
||||
<para>If set to <literal>copy-host</literal>, the <filename>/etc/resolv.conf</filename> file from the
|
||||
host is copied into the container, unless the file exists already and is not a regular file (e.g. a
|
||||
symlink). Similar, if <literal>replace-host</literal> is used the file is copied, replacing any
|
||||
existing inode, including symlinks. Similar, if <literal>bind-host</literal> is used, the file is
|
||||
symlink). Similarly, if <literal>replace-host</literal> is used the file is copied, replacing any
|
||||
existing inode, including symlinks. Similarly, if <literal>bind-host</literal> is used, the file is
|
||||
bind mounted from the host into the container.</para>
|
||||
|
||||
<para>If set to <literal>copy-static</literal>, <literal>replace-static</literal> or
|
||||
|
@ -67,11 +67,12 @@
|
||||
command has begun execution (unless <option>--no-block</option> or <option>--wait</option> are specified, see
|
||||
below).</para>
|
||||
|
||||
<para>If a command is run as transient scope unit, it will be executed by <command>systemd-run</command> itself as
|
||||
parent process and will thus inherit the execution environment of the caller. However, the processes of the command
|
||||
are managed by the service manager similar to normal services, and will show up in the output of <command>systemctl
|
||||
list-units</command>. Execution in this case is synchronous, and will return only when the command finishes. This
|
||||
mode is enabled via the <option>--scope</option> switch (see below). </para>
|
||||
<para>If a command is run as transient scope unit, it will be executed by <command>systemd-run</command>
|
||||
itself as parent process and will thus inherit the execution environment of the caller. However, the
|
||||
processes of the command are managed by the service manager similarly to normal services, and will show
|
||||
up in the output of <command>systemctl list-units</command>. Execution in this case is synchronous, and
|
||||
will return only when the command finishes. This mode is enabled via the <option>--scope</option> switch
|
||||
(see below). </para>
|
||||
|
||||
<para>If a command is run with path, socket, or timer options such as <option>--on-calendar=</option> (see below),
|
||||
a transient path, socket, or timer unit is created alongside the service unit for the specified command. Only the
|
||||
@ -234,8 +235,8 @@
|
||||
<term><option>--same-dir</option></term>
|
||||
<term><option>-d</option></term>
|
||||
|
||||
<listitem><para>Similar to <option>--working-directory=</option> but uses the current working directory of the
|
||||
caller for the service to execute.</para></listitem>
|
||||
<listitem><para>Similar to <option>--working-directory=</option>, but uses the current working
|
||||
directory of the caller for the service to execute.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
@ -354,9 +355,9 @@
|
||||
<term><option>--socket-property=</option></term>
|
||||
<term><option>--timer-property=</option></term>
|
||||
|
||||
<listitem><para>Sets a property on the path, socket, or timer unit that is created. This option is similar to
|
||||
<option>--property=</option> but applies to the transient path, socket, or timer unit rather than the
|
||||
transient service unit created. This option takes an assignment in the same format as
|
||||
<listitem><para>Sets a property on the path, socket, or timer unit that is created. This option is
|
||||
similar to <option>--property=</option>, but applies to the transient path, socket, or timer unit
|
||||
rather than the transient service unit created. This option takes an assignment in the same format as
|
||||
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
||||
<command>set-property</command> command. These options may not be combined with
|
||||
<option>--scope</option> or <option>--pty</option>.</para>
|
||||
|
@ -1227,7 +1227,7 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
|
||||
affecting the process' ability to operate. Note that many of these sandboxing features are gracefully turned off on
|
||||
systems where the underlying security mechanism is not available. For example, <varname>ProtectSystem=</varname>
|
||||
has no effect if the kernel is built without file system namespacing or if the service manager runs in a container
|
||||
manager that makes file system namespacing unavailable to its payload. Similar,
|
||||
manager that makes file system namespacing unavailable to its payload. Similarly,
|
||||
<varname>RestrictRealtime=</varname> has no effect on systems that lack support for SECCOMP system call filtering,
|
||||
or in containers where support for this is turned off.</para>
|
||||
|
||||
@ -2536,14 +2536,15 @@ SystemCallErrorNumber=EPERM</programlisting>
|
||||
<varlistentry>
|
||||
<term><varname>EnvironmentFile=</varname></term>
|
||||
|
||||
<listitem><para>Similar to <varname>Environment=</varname> but reads the environment variables from a text file.
|
||||
The text file should contain newline-separated variable assignments. Empty lines, lines without an
|
||||
<literal>=</literal> separator, or lines starting with <literal>;</literal> or <literal>#</literal> will be
|
||||
ignored, which may be used for commenting. The file must be UTF-8 encoded. Valid characters are <ulink
|
||||
url="https://www.unicode.org/glossary/#unicode_scalar_value">unicode scalar values</ulink> other than <ulink
|
||||
url="https://www.unicode.org/glossary/#noncharacter">noncharacters</ulink>, U+0000 NUL, and U+FEFF <ulink
|
||||
url="https://www.unicode.org/glossary/#byte_order_mark">byte order mark</ulink>. Control codes other than NUL
|
||||
are allowed.</para>
|
||||
<listitem><para>Similar to <varname>Environment=</varname>, but reads the environment variables from
|
||||
a text file. The text file should contain newline-separated variable assignments. Empty lines, lines
|
||||
without an <literal>=</literal> separator, or lines starting with <literal>;</literal> or
|
||||
<literal>#</literal> will be ignored, which may be used for commenting. The file must be UTF-8
|
||||
encoded. Valid characters are <ulink
|
||||
url="https://www.unicode.org/glossary/#unicode_scalar_value">unicode scalar values</ulink> other than
|
||||
<ulink url="https://www.unicode.org/glossary/#noncharacter">noncharacters</ulink>, U+0000 NUL, and
|
||||
U+FEFF <ulink url="https://www.unicode.org/glossary/#byte_order_mark">byte order mark</ulink>.
|
||||
Control codes other than NUL are allowed.</para>
|
||||
|
||||
<para>In the file, an unquoted value after the <literal>=</literal> is parsed with the same backslash-escape
|
||||
rules as <ulink
|
||||
@ -2933,8 +2934,8 @@ StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZX
|
||||
<para>Internally, journal namespaces are implemented through Linux mount namespacing and
|
||||
over-mounting the directory that contains the relevant <constant>AF_UNIX</constant> sockets used for
|
||||
logging in the unit's mount namespace. Since mount namespaces are used this setting disconnects
|
||||
propagation of mounts from the unit's processes to the host, similar to how
|
||||
<varname>ReadOnlyPaths=</varname> and similar settings (see above) work. Journal namespaces may hence
|
||||
propagation of mounts from the unit's processes to the host, similarly to how
|
||||
<varname>ReadOnlyPaths=</varname> and similar settings describe above work. Journal namespaces may hence
|
||||
not be used for services that need to establish mount points on the host.</para>
|
||||
|
||||
<para>When this option is used the unit will automatically gain ordering and requirement dependencies
|
||||
@ -3381,14 +3382,14 @@ StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZX
|
||||
|
||||
<listitem><para>The PID of the unit's main process if it is
|
||||
known. This is only set for control processes as invoked by
|
||||
<varname>ExecReload=</varname> and similar. </para></listitem>
|
||||
<varname>ExecReload=</varname> and similar.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>$MANAGERPID</varname></term>
|
||||
|
||||
<listitem><para>The PID of the user <command>systemd</command>
|
||||
instance, set for processes spawned by it. </para></listitem>
|
||||
instance, set for processes spawned by it.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
@ -3426,7 +3427,7 @@ StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZX
|
||||
<listitem><para>The PID of the unit process (e.g. process invoked by
|
||||
<varname>ExecStart=</varname>). The child process can use this information to determine
|
||||
whether the process is directly invoked by the service manager or indirectly as a child of
|
||||
another process by comparing this value with the current PID (as similar to the scheme used in
|
||||
another process by comparing this value with the current PID (similarly to the scheme used in
|
||||
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
with <varname>$LISTEN_PID</varname> and <varname>$LISTEN_FDS</varname>).</para></listitem>
|
||||
</varlistentry>
|
||||
|
@ -1900,12 +1900,12 @@ Table=1234</programlisting></para>
|
||||
<varlistentry>
|
||||
<term><varname>UseDomains=</varname></term>
|
||||
<listitem>
|
||||
<para>Takes a boolean, or the special value <option>route</option>. When true, the domain
|
||||
name received from the DHCP server will be used as DNS search domain over this link, similar
|
||||
to the effect of the <option>Domains=</option> setting. If set to <option>route</option>, the
|
||||
domain name received from the DHCP server will be used for routing DNS queries only, but not
|
||||
for searching, similar to the effect of the <option>Domains=</option> setting when the
|
||||
argument is prefixed with <literal>~</literal>. Defaults to false.</para>
|
||||
<para>Takes a boolean, or the special value <option>route</option>. When true, the domain name
|
||||
received from the DHCP server will be used as DNS search domain over this link, similarly to the
|
||||
effect of the <option>Domains=</option> setting. If set to <option>route</option>, the domain name
|
||||
received from the DHCP server will be used for routing DNS queries only, but not for searching,
|
||||
similarly to the effect of the <option>Domains=</option> setting when the argument is prefixed with
|
||||
<literal>~</literal>. Defaults to false.</para>
|
||||
|
||||
<para>It is recommended to enable this option only on trusted networks, as setting this
|
||||
affects resolution of all hostnames, in particular of single-label names. It is generally
|
||||
@ -2399,11 +2399,11 @@ Token=prefixstable:2002:da8:1::</programlisting></para>
|
||||
<term><varname>UseDomains=</varname></term>
|
||||
<listitem>
|
||||
<para>Takes a boolean, or the special value <literal>route</literal>. When true, the domain name
|
||||
received via IPv6 Router Advertisement (RA) will be used as DNS search domain over this link, similar to
|
||||
the effect of the <option>Domains=</option> setting. If set to <literal>route</literal>, the domain name
|
||||
received via IPv6 RA will be used for routing DNS queries only, but not for searching, similar to the
|
||||
effect of the <option>Domains=</option> setting when the argument is prefixed with
|
||||
<literal>~</literal>. Defaults to false.</para>
|
||||
received via IPv6 Router Advertisement (RA) will be used as DNS search domain over this link,
|
||||
similarly to the effect of the <option>Domains=</option> setting. If set to
|
||||
<literal>route</literal>, the domain name received via IPv6 RA will be used for routing DNS queries
|
||||
only, but not for searching, similarly to the effect of the <option>Domains=</option> setting when
|
||||
the argument is prefixed with <literal>~</literal>. Defaults to false.</para>
|
||||
|
||||
<para>It is recommended to enable this option only on trusted networks, as setting this affects resolution
|
||||
of all hostnames, in particular of single-label names. It is generally safer to use the supplied domain
|
||||
@ -2924,7 +2924,7 @@ Token=prefixstable:2002:da8:1::</programlisting></para>
|
||||
<varlistentry>
|
||||
<term><varname>Prefix=</varname></term>
|
||||
|
||||
<listitem><para>The IPv6 prefix that is to be distributed to hosts. Similarly to configuring static
|
||||
<listitem><para>The IPv6 prefix that is to be distributed to hosts. Similarly to configuring static
|
||||
IPv6 addresses, the setting is configured as an IPv6 prefix and its prefix length, separated by a
|
||||
<literal>/</literal> character. Use multiple [IPv6Prefix] sections to configure multiple IPv6
|
||||
prefixes since prefix lifetimes, address autoconfiguration and onlink status may differ from one
|
||||
@ -2979,7 +2979,7 @@ Token=prefixstable:2002:da8:1::</programlisting></para>
|
||||
<varlistentry>
|
||||
<term><varname>Route=</varname></term>
|
||||
|
||||
<listitem><para>The IPv6 route that is to be distributed to hosts. Similarly to configuring static
|
||||
<listitem><para>The IPv6 route that is to be distributed to hosts. Similarly to configuring static
|
||||
IPv6 routes, the setting is configured as an IPv6 prefix routes and its prefix route length,
|
||||
separated by a <literal>/</literal> character. Use multiple [IPv6RoutePrefix] sections to configure
|
||||
multiple IPv6 prefix routes.</para></listitem>
|
||||
|
@ -122,7 +122,7 @@
|
||||
<varname>PathExists=</varname> may be used to watch the mere
|
||||
existence of a file or directory. If the file specified
|
||||
exists, the configured unit is activated.
|
||||
<varname>PathExistsGlob=</varname> works similar, but checks
|
||||
<varname>PathExistsGlob=</varname> works similarly, but checks
|
||||
for the existence of at least one file matching the globbing
|
||||
pattern specified. <varname>PathChanged=</varname> may be used
|
||||
to watch a file or directory and activate the configured unit
|
||||
|
@ -1152,9 +1152,9 @@
|
||||
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||||
details.</para>
|
||||
|
||||
<para>This setting also applies to <command>systemd-oomd</command>, similar to the kernel OOM kills
|
||||
this setting determines the state of the service after <command>systemd-oomd</command> kills a cgroup
|
||||
associated with the service.</para></listitem>
|
||||
<para>This setting also applies to <command>systemd-oomd</command>. Similarly to the kernel OOM
|
||||
kills, this setting determines the state of the service after <command>systemd-oomd</command> kills a
|
||||
cgroup associated with the service.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
Loading…
Reference in New Issue
Block a user