[systemd-bugs] [Bug 77507] systemctl status exits with failure status for a service that completed successfully

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Dec 18 13:54:53 PST 2014


https://bugs.freedesktop.org/show_bug.cgi?id=77507

--- Comment #2 from van.de.bugger at gmail.com ---
I would not agree, it is *not* a corner case. Look at systemctl man page
(http://www.freedesktop.org/software/systemd/man/systemctl.html): at the
bottom, in "Exit status" section, it says:

    On success, 0 is returned, a non-zero failure code otherwise.

That's all. Subsection "status" says nothing about systemctl exit status at
all. If systemctl follows LSB semantics for init scripts, it should be
documented at least. 

BUT... there is a difference between init scripts and systemctl. A script
reports status of one service controlled by this script. systemctl allows
specifying multiple services in one command line, e. g.:

    systemctl status autofs sshd crond

or even

    systemctl --all status

How are you going to follow LSB semantics in such a case?

BTW, exit status problem is not limited by status command. is-active,
is-failed, is-enabled also suffer from lack of documentation/specification. 

For example, man page says about is-active:

>    Check whether any of the specified units are active (i.e. running). Returns an exit code 0 if at least one is active, or non-zero otherwise. 

Description of -s-failed is very similar:

>    Check whether any of the specified units are in a "failed" state. Returns an exit code 0 if at least one has failed, non-zero otherwise.

It is better than "status", but not enough. Look:

    $ systemctl -q is-active syslog; echo $?
    3

    $ systemctl -q is-active syslg; echo $?
    3

These are two very distinct cases: in the first case syslog service exists but
is not active, in the second case there is no "syslg" service at all.  Let us
check is-failed then:

    $ systemctl -q is-failed syslog; echo $?
    1

    $ systemctl -q is-failed syslg; echo $?
    1

It meets current man ("non-zero otherwise"), but it is non-consistent at least.
Why one command returns 3 but another command returns 1 in similar case?

I do not recommend to follow LSB semantics for init scripts because it is
neither user-oriented nor complete:

    0. program is running or service is OK
    1. program is dead and /var/run pid file exists
    2. program is dead and /var/lock lock file exists
    3. program is not running

For example, an oneshot service can be active even if program is not running.
If I understand correctly, systemd uses control groups to stop or kill
services, so pid files and lock files are not so important now. 

I would recommend following simpler but more universal semantics:

    0. Success or true. 
    1. Success but false.
    > 1. Trouble.

For example:

    $ systemctl is-active xxx

returns 0 if service xxx is active, 1 if service is known but not active, and
some status bigger than 1 in case of troubles: command-line error (e. g.
unknown option), runtime error (unit file is not readable), etc.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20141218/476ba7c0/attachment.html>


More information about the systemd-bugs mailing list