Bug 1281612 - vgchange --activationmode partial -ay exits without error, but outputs message to STDERR
vgchange --activationmode partial -ay exits without error, but outputs messag...
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-12 18:10 EST by Tony Asleson
Modified: 2017-07-25 15:40 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-25 15:40:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tony Asleson 2015-11-12 18:10:00 EST
Description of problem:

If you activate a VG using:

# vgchange --activationmode partial -ay foo

you get:

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

How reproducible:


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.
Comment 1 Tony Asleson 2015-11-12 18:26:02 EST

Example should be:

# vgchange --activationmode partial -ay pwffzluh_vg

I copied & pasted incorrect command from unit test case for the output.
Comment 2 Alasdair Kergon 2015-11-12 18:43:48 EST
This is the intended behaviour at the moment.
We issue warning messages like that on stderr.
Comment 3 Tony Asleson 2015-11-12 18:55:49 EST
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.
Comment 4 Alasdair Kergon 2015-11-12 19:00:41 EST
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?
Comment 5 Tony Asleson 2015-11-12 19:05:25 EST
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.
Comment 6 Zdenek Kabelac 2015-11-13 03:25:19 EST
(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.
Comment 7 Tony Asleson 2016-01-08 16:46:44 EST
Proposed return code which addresses this:
Comment 8 Tony Asleson 2016-01-08 16:47:47 EST
(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:
Comment 9 Jan Kurik 2016-02-24 08:57:09 EST
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:
Comment 10 Fedora End Of Life 2017-07-25 15:29:00 EDT
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.
Comment 11 Tony Asleson 2017-07-25 15:40:08 EDT
Lvm logs all kinds of things to stderr even when successful, closing.

Note You need to log in before you can comment on or make changes to this bug.