shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-03-21 02:50:18 +03:00
Code

Merge pull request #18735 from poettering/some-doc-fixes

Browse Source 
three documentation fixes
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2021-02-22 19:45:01 +01:00 committed by GitHub
commit e6c31188dc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 29 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/DISCOVERABLE_PARTITIONS.md
View File

@ -226,7 +226,7 @@ appliance-like installations.
### What partitioning tools will create a DPS-compliant partition table?
As of util-linux 2.25.2, the `fdisk` tool provides type codes to create the
root, home, and swap partitions that the DPS expects, By default, `fdisk` will
root, home, and swap partitions that the DPS expects. By default, `fdisk` will
create an old-style MBR, not a GPT, so typing `l` to list partition types will
not show the choices to let you set the correct UUID. Make sure to first create
an empty GPT, then type `l` in order for the DPS-compliant type codes to be

12
man/systemd.exec.xml
View File

@ -2408,7 +2408,9 @@ SystemCallErrorNumber=EPERM</programlisting>
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
details about named file descriptors and their ordering.</para>
<para>This setting defaults to <option>null</option>.</para></listitem>
<para>This setting defaults to <option>null</option>, unless
<varname>StandardInputText=</varname>/<varname>StandardInputData=</varname> are set, in which case it
defaults to <option>data</option>.</para></listitem>
</varlistentry>
<varlistentry>
@ -2522,9 +2524,11 @@ SystemCallErrorNumber=EPERM</programlisting>
<term><varname>StandardInputText=</varname></term>
<term><varname>StandardInputData=</varname></term>
<listitem><para>Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the
executed processes. These settings have no effect unless <varname>StandardInput=</varname> is set to
<option>data</option>. Use this option to embed process input data directly in the unit file.</para>
<listitem><para>Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to
the executed processes. These settings have no effect unless <varname>StandardInput=</varname> is set
to <option>data</option> (which is the default if <varname>StandardInput=</varname> is not set
otherwise, but <varname>StandardInputText=</varname>/<varname>StandardInputData=</varname> is). Use
this option to embed process input data directly in the unit file.</para>
<para><varname>StandardInputText=</varname> accepts arbitrary textual data. C-style escapes for special
characters as well as the usual <literal>%</literal>-specifiers are resolved. Each time this setting is used

36
man/systemd.unit.xml
View File

@ -1063,28 +1063,32 @@
<refsect2>
<title>Conditions and Asserts</title>
<para>Unit files may also include a number of <varname index="false">Condition…=</varname> and
<varname index="false">Assert…=</varname> settings. Before the unit is started, systemd will verify
that the specified conditions are true. If not, the starting of the unit will be (mostly silently)
skipped. Failing conditions will not result in the unit being moved into the <literal>failed</literal>
state. The conditions are checked at the time the queued start job is to be executed. The ordering
dependencies are still respected, so other units are still pulled in and ordered as if this unit was
successfully activated. Use condition expressions in order to skip units that do not apply to the local
system, for example because the kernel or runtime environment doesn't require their functionality.
<para>Unit files may also include a number of <varname index="false">Condition…=</varname> and <varname
index="false">Assert…=</varname> settings. Before the unit is started, systemd will verify that the
specified conditions and asserts are true. If not, the starting of the unit will be (mostly silently)
skipped (in case of conditions), or aborted with an error message (in case of asserts). Failing
conditions or asserts will not result in the unit being moved into the <literal>failed</literal>
state. The conditions and asserts are checked at the time the queued start job is to be executed. The
ordering dependencies are still respected, so other units are still pulled in and ordered as if this
unit was successfully activated, and the conditions and asserts are executed the precise moment the
unit would normally start and thus can validate system state after the units ordered before completed
initialization. Use condition expressions for skipping units that do not apply to the local system, for
example because the kernel or runtime environment doesn't require their functionality.
</para>
<para>If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a
logical AND is applied). Condition checks can use a pipe symbol (<literal>|</literal>) after the equals
sign (<literal>Condition…=|…</literal>), which causes the condition becomes a triggering condition. If
at least one triggering condition is defined for a unit, then the unit will be executed if at least one
of the triggering conditions apply and all of the non-triggering conditions. If you prefix an argument
with the pipe symbol and an exclamation mark, the pipe symbol must be passed first, the exclamation
second. If any of these options is assigned the empty string, the list of conditions is reset
completely, all previous condition settings (of any kind) will have no effect.</para>
sign (<literal>Condition…=|…</literal>), which causes the condition to become a
<emphasis>triggering</emphasis> condition. If at least one triggering condition is defined for a unit,
then the unit will be started if at least one of the triggering conditions of the unit applies and all
of the regular (i.e. non-triggering) conditions apply. If you prefix an argument with the pipe symbol
and an exclamation mark, the pipe symbol must be passed first, the exclamation second. If any of these
options is assigned the empty string, the list of conditions is reset completely, all previous
condition settings (of any kind) will have no effect.</para>
<para>The <varname>AssertArchitecture=</varname>, <varname>AssertVirtualization=</varname>, … options
provide a similar mechanism that causes the job to fail (instead of being skipped). The failed check is
logged. Units with failed conditions are considered to be in a clean state and will be garbage
are similar to conditions but cause the start job to fail (instead of being skipped). The failed check
is logged. Units with failed conditions are considered to be in a clean state and will be garbage
collected if they are not referenced. This means that when queried, the condition failure may or may
not show up in the state of the unit.</para>