Red Hat Bugzilla – Bug 1281612
vgchange --activationmode partial -ay exits without error, but outputs message to STDERR
Last modified: 2017-07-25 15:40:08 EDT
Description of problem:
If you activate a VG using:
# vgchange --activationmode partial -ay foo
exit code == 0
1 logical volume(s) in volume group "pwffzluh_vg" now active
PARTIAL MODE. Incomplete logical volumes will be processed.
Version-Release number of selected component (if applicable):
Don't believe this is version specific, but this is what I was using.
LVM version: 2.02.133(2) (2015-10-30)
Library version: 1.02.110 (2015-10-30)
Driver version: 4.33.0
Steps to Reproduce:
Activate a VG using partial activation mode, see above.
Output in std error
No output in STDERR when exit code == 0
When you are running in the context of lvm shell we have no exit code so we treat anything to STDERR as a failure of the command.
Example should be:
# vgchange --activationmode partial -ay pwffzluh_vg
I copied & pasted incorrect command from unit test case for the output.
This is the intended behaviour at the moment.
We issue warning messages like that on stderr.
If we don't change this we cannot leverage using lvm shell for the dbus service as we cannot tell if something succeeded or failed. Blivet has expressed that they want to minimize forking, so lvm needs to stop outputting to STDERR on success or come up with a way to express the exit code in lvm shell.
We already discussed providing the error code for the shell (in the prompt). Did that make it as far as bugzilla or should we use this one?
This could also be addressed with JSON output too. We can use this issue to track adding an exit code to the lvm shell if we cannot move non-fatal output from STDERR to STDOUT.
(In reply to Alasdair Kergon from comment #2)
> This is the intended behaviour at the moment.
> We issue warning messages like that on stderr.
It's questionable whether this is 'warning'-type message or rather informational message.
So IMHO Tony's interpretation seems more correct - command has not produced any error - worked as commanded and doing requested thing - thus we should try to keep stderr for 'real/unexpected' trouble messages.
Providing 'error' codes does mean ATM major rework.
Proposed return code which addresses this:
(In reply to Tony Asleson from comment #7)
> Proposed return code which addresses this:
Patch also depends on:
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.
More information and reason for this action is here:
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Lvm logs all kinds of things to stderr even when successful, closing.