qvm-check's output and retcode kind of buggy

[ghost]

Qubes OS version:

R4.0 rc3

---

Steps to reproduce the behavior:

I'm scripting some stuff in dom0 and need to check if a VM exists ; qvm-check seems to be the way to go rather than grepping the output of qvm-ls.

Let's assume that a VM named "work" exists and that a VM named "work1" doesn't.

Case 1: checking if VM "work" is running: works as expected

[user@dom0 ~]$ qvm-check work
VM work exists
[user@dom0 ~]$ echo $?
0

Case 2: adding the --quiet arg: the output isn't suppressed

[user@dom0 ~]$ qvm-check --quiet work
VM work exists

Case 3: finding out what the retcode for a wrong syntax is (to compare with case 4 below)

[user@dom0 ~]$ qvm-check --blahblah
[...]
[user@dom0 ~]$ echo $?
2

Case 4: checking if a non existent VM exists: usage() is displayed and usage()'s retcode is returned despite the syntax being right; one would expect the retcode "1"

[user@dom0 ~]$ qvm-check work1
usage: qvm-check [-h] [--verbose] [--quiet] [--all] [--exclude EXCLUDE]
                 [--running] [--paused] [--template]
                 [VMNAME [VMNAME ...]]
qvm-check: error: no such domain: 'work1'
[user@dom0 ~]$ echo $?
2

I looked at /usr/lib/python3.5/site-packages/qubesadmin/tests/tools/qvm_check.py to try to fix it and send a PR, but it was a bit too cryptic for me.

Very minor issue BTW.

[esote]

@taradiddles It looks like most Qubes tools return 2 when printing the error help message. This includes from an incorrect flag.

@marmarek What GH repository is this tool in? I checked here but the opt parsing doesn't have --quiet. Also, what is the expected behavior for a nonexistant VM (such as case 4). I'm in favor of printing "VM vmname does not exist" & an error return code.

[marmarek]

@esote this is the right place, generic options (like --verbose, --help, --quiet) are handled by qubesadmin.tools.QubesArgumentParser
It adjust loglevel of default logger, but that qvm-check messages use print directly instead of app.log.

[3hhh]

From my point of view more relevant is this one:

qvm-check --running existingRunning existingNotRunning &> /dev/null
echo $?
0

The message says something about existingNotRunning not running, but the error code should reflect that. What one usually does is add up all non-running VMs and use that as error code or set an error code dedicated to "some VMs are running, some are not".

[ghost]

FYI --quiet not being honored (case 2 in my original post) was fixed but case 4 is still present on 4.1: qvm-check --quiet nonExistentVm still spews the same error despite the --quiet option (and in that case retcode is 2 - the same as eg. a wrong option)

so if using qvm-check in scripts, either add 2>&1 > /dev/null (not only ugly but totally unreliable), or - better but more convoluted - parse the output of qvm-ls.

[DemiMarie]

Presumably still an issue in R4.1. Validating qube names during command line option parsing is a misdesign IMO, and causes other problems as well. For instance, qvm-shutdown DoesNotExist emits a usage message.

[ghost]

Presumably still an issue in R4.1

Yes: --quiet is ignored + wrong exit code (2: same as "unrecognized arguments" error code)

[user@dom0 ~]$ qvm-check --quiet dsad
usage: qvm-check [--verbose] [--quiet] [--help] [--all] [--exclude EXCLUDE] [--running] [--paused] [--template] [--networked] [VMNAME [VMNAME ...]]
qvm-check: error: no such domain: 'dsad'
[user@dom0 ~]$ echo $?
2

Temporary workaround: qube=somevm ; qvm-ls --raw-list | grep -q "^${qube}$" && [...]

[alimirjamali]

Is this the last remaining bug of qvm-check which is discussed in this issue and remains unsolved:

Yes: --quiet is ignored + wrong exit code (2: same as "unrecognized arguments" error code)

In that case, the above PR would hopefully solve it.

p.s.: As always, PR reviews are highly appreciated