diff options
| author | Colin Walters <walters@verbum.org> | 2022-08-31 22:39:03 +0200 |
|---|---|---|
| committer | Yu Watanabe <watanabe.yu+github@gmail.com> | 2022-09-01 08:03:40 +0200 |
| commit | 413e8650b71d4404a7453403797f93d73d88c466 (patch) | |
| tree | eb65f6ddda014e3a81fb74869f9ffa24fe182a71 /man/systemd.unit.xml | |
| parent | udevadm-settle: improve logs when we cannot access /run/udev/control (diff) | |
| download | systemd-413e8650b71d4404a7453403797f93d73d88c466.tar.xz systemd-413e8650b71d4404a7453403797f93d73d88c466.zip | |
tree-wide: Use "unmet" for condition checks, not "failed"
Often I end up debugging a problem on a system, and I
do e.g. `journalctl --grep=failed|error`. The use of the term
"failed" for condition checks adds a *lot* of unnecessary noise into
this.
Now, I know this regexp search isn't precise, but it has proven
to be useful to me.
I think "failed" is too strong of a term as a baseline, and also
just stands out to e.g. humans watching their servers boot or
whatever.
The term "met condition" is fairly widely used, e.g.
https://stackoverflow.com/questions/63751794/what-does-the-condition-is-met-exactly-mean-in-programming-languages
Use that instead.
Diffstat (limited to 'man/systemd.unit.xml')
| -rw-r--r-- | man/systemd.unit.xml | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index a9114fb353..7c1f7186e2 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -705,7 +705,7 @@ <para>When used in conjunction with <varname>After=</varname> on the same unit the behaviour of <varname>BindsTo=</varname> is even stronger. In this case, the unit bound to strictly has to be in active state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly - enters inactive state, but also one that is bound to another unit that gets skipped due to a failed condition + enters inactive state, but also one that is bound to another unit that gets skipped due to an unmet condition check (such as <varname>ConditionPathExists=</varname>, <varname>ConditionPathIsSymbolicLink=</varname>, … — see below) will be stopped, should it be running. Hence, in many cases it is best to combine <varname>BindsTo=</varname> with <varname>After=</varname>.</para> @@ -1170,7 +1170,7 @@ <para>The <varname>AssertArchitecture=</varname>, <varname>AssertVirtualization=</varname>, … options 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 + is logged. Units with unmet 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> |