mirror of
https://github.com/morgan9e/systemd
synced 2026-04-14 00:14:32 +09:00
man: clarify what “failed” means
systemd.service(5)’s documentation of `ExecCondition=` uses “failed” with respect to the unit active state. In particular the unit won’t be considered failed when `ExecCondition=`’s command exits with a status of 1 through 254 (inclusive). It will however, when it exits with 255 or abnormally (e.g. timeout, killed by a signal, etc.). The table “Defined $SERVICE_RESULT values” in systemd.exec(5) uses “failed” however rather with respect to the condition. Tests seem to have shown that, if the exit status of the `ExecCondition=` command is one of 1 through 254 (inclusive), `$SERVICE_RESULT` will be `exec-condition`, if it is 255, `$SERVICE_RESULT` will be `exit-code` (but `$EXIT_CODE` and `$EXIT_STATUS` will be empty or unset), if it’s killed because of `SIGKILL`, `$SERVICE_RESULT` will `signal` and if it times out, `$SERVICE_RESULT` will be `timeout`. This commit clarifies the table at least for the case of an exit status of 1 through 254 (inclusive). The others (signal, timeout and 255 are probably also still ambiguous (e.g. `signal` uses “A service process”, which could be considered as the actual service process only). Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
This commit is contained in:
committed by
Zbigniew Jędrzejewski-Szmek
parent
b1aa33ff91
commit
07f4718242
@@ -4366,7 +4366,7 @@ StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZX
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>exec-condition</literal></entry>
|
||||
<entry>Service did not run because <varname>ExecCondition=</varname> failed.</entry>
|
||||
<entry>Service did not run because <varname>ExecCondition=</varname> failed (that is its command exited with an exit status of 1 through 254 (inclusive)).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>oom-kill</literal></entry>
|
||||
|
||||
Reference in New Issue
Block a user