Description of problem: If you activate a VG using: # vgchange --activationmode partial -ay foo you get: exit code == 0 STDOUT = 1 logical volume(s) in volume group "pwffzluh_vg" now active STDERR = 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 How reproducible: Always Steps to Reproduce: Activate a VG using partial activation mode, see above. Actual results: Output in std error Expected results: No output in STDERR when exit code == 0 Additional info: 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.
Correction: 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: https://www.redhat.com/archives/lvm-devel/2016-January/msg00007.html
(In reply to Tony Asleson from comment #7) > Proposed return code which addresses this: > https://www.redhat.com/archives/lvm-devel/2016-January/msg00007.html Patch also depends on: https://www.redhat.com/archives/lvm-devel/2016-January/msg00006.html
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: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
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' of '24'. 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.