Bug 1281612

Summary:	vgchange --activationmode partial -ay exits without error, but outputs message to STDERR
Product:	[Fedora] Fedora	Reporter:	Tony Asleson <tasleson>
Component:	lvm2	Assignee:	LVM and device-mapper development team <lvm-team>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	24	CC:	agk, bmarzins, bmr, dwysocha, heinzm, jonathan, lvm-team, msnitzer, prajnoha, prockai, zkabelac
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-25 19:40:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tony Asleson 2015-11-12 23:10:00 UTC

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.

Comment 1 Tony Asleson 2015-11-12 23:26:02 UTC

Correction:

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 23:43:48 UTC

This is the intended behaviour at the moment.
We issue warning messages like that on stderr.

Comment 3 Tony Asleson 2015-11-12 23:55:49 UTC

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-13 00:00:41 UTC

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-13 00:05:25 UTC

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 08:25:19 UTC

(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 21:46:44 UTC

Proposed return code which addresses this:
https://www.redhat.com/archives/lvm-devel/2016-January/msg00007.html

Comment 8 Tony Asleson 2016-01-08 21:47:47 UTC

(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

Comment 9 Jan Kurik 2016-02-24 13:57:09 UTC

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

Comment 10 Fedora End Of Life 2017-07-25 19:29:00 UTC

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 19:40:08 UTC

Lvm logs all kinds of things to stderr even when successful, closing.