]> git.ipfire.org Git - thirdparty/systemd.git/commit
man: clarify what “failed” means
authorChristoph Anton Mitterer <mail@christoph.anton.mitterer.name>
Sun, 2 Nov 2025 19:13:35 +0000 (20:13 +0100)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Thu, 6 Nov 2025 09:47:06 +0000 (10:47 +0100)
commit07f471824288433d17ebe097e94dfca85e74fea6
treeccbcfb1a5a59655dd66a55a249de7f61c631f5d8
parentb1aa33ff916d67d54103474e81ca612e3d4b9e59
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>
man/systemd.exec.xml