RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1365186 - lvextend changed return code when called with current LV size
Summary: lvextend changed return code when called with current LV size
Keywords:
Status: CLOSED DUPLICATE of bug 1354396
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.2
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
Milan Navratil
URL:
Whiteboard:
Depends On:
Blocks: 1364339 1366176 1366991
TreeView+ depends on / blocked
 
Reported: 2016-08-08 14:53 UTC by Adam Litke
Modified: 2021-09-03 12:38 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Please document as Known Issue for RHEL7.3 Beta Cause: Consequence: Workaround (if any): Result:
Clone Of:
Environment:
Last Closed: 2016-08-24 23:11:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Reproducer (run as root) (576 bytes, application/x-shellscript)
2016-08-08 14:53 UTC, Adam Litke 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1354396 0 medium CLOSED lvmresize: resize of unchanged LV should not try to resize FS 2021-09-03 12:51:18 UTC

Internal Links: 1354396

Description Adam Litke 2016-08-08 14:53:10 UTC 
Created attachment 1188817 [details]
Reproducer (run as root)

Description of problem:

When calling lvextend with a size equal to the current LV size, the command should fail with rc=3.  It is now failing with rc=5 which breaks its API and causes management programs to misinterpret the error.


Version-Release number of selected component (if applicable):
lvm2-2.02.161-3.el7.x86_64


How reproducible:
Always


Steps to Reproduce:
1. Call lvextend on an LV using the current LV size

Actual results:
Command fails with rc=5


Expected results:
Command fails with rc=3


Additional info:
See test script to be attached.
Comment 1 Zdenek Kabelac 2016-08-10 18:34:04 UTC 
This is a bugfix.

To know the size of a LV -  metadata needs to be opened and parsed.

Return code 3 is returned (or should be returned) only in the case metadata were not yet opened (lock not grabbed) and invalid command line args were given.

Return code 5 is the ONLY correct one here in this case.

You can't rely on return code 3 to detect 'same size' - that's clear bug in application (and in fact this bug should have been reported)...
Comment 2 Yaniv Lavi 2016-08-11 12:24:30 UTC 
You are breaking a layer product and such changes should be done with care.
Please consider reverting this until we are able to adept. Changing this without any prior notice make it very hard to resolve.
Comment 3 Yaniv Kaul 2016-08-15 08:38:59 UTC 
*** Bug 1366176 has been marked as a duplicate of this bug. ***
Comment 4 Zdenek Kabelac 2016-08-15 09:13:12 UTC 
(In reply to Yaniv Dary from comment #2)
> You are breaking a layer product and such changes should be done with care.
> Please consider reverting this until we are able to adept. Changing this
> without any prior notice make it very hard to resolve.

You were clearly misusing 'undocumented' observed buggy behavior. Instead you should have immediately report a bug where return code 3 has been returned after VG metadata has been parsed.

Do you expect  lvm2  to support every released bug in every release forever - like having approximately 50 new config options per every version to enable/disable every bug found during develeopment ?
Comment 5 Alasdair Kergon 2016-08-15 11:08:30 UTC 
The only reliable method is to obtain the size explicitly and compare it, if you want to check whether or not the size is the same (or use --select).  Relying on the distinction between code 3 and 5 is always going to lead to fragile code, I'm afraid.  We may be rewriting more of this code soon too, which will no doubt lead to some more similar cases of individual errors changing for better overall consistency.
Comment 7 Nir Soffer 2016-08-15 13:30:57 UTC 
(In reply to Zdenek Kabelac from comment #4)
> (In reply to Yaniv Dary from comment #2)
> > You are breaking a layer product and such changes should be done with care.
> > Please consider reverting this until we are able to adept. Changing this
> > without any prior notice make it very hard to resolve.
> 
> You were clearly misusing 'undocumented' observed buggy behavior. Instead
> you should have immediately report a bug where return code 3 has been
> returned after VG metadata has been parsed.

Can you point me to the lvm bug about "fixing" the error code when extending
an lv?

We expect zero backward incompatible changes in minor versions. Changing
behaviour (even undocumented) must be done only in major version.
Comment 8 Alasdair Kergon 2016-08-15 14:13:11 UTC 
All we say in the man page is:

DIAGNOSTICS
       All tools return a status code of zero on success or non-zero on  fail-
       ure.

We can add another sentence there to make the policy clearer to people who haven't asked.

The exit code is only a guide as to whether the failure was probably due to incorrect syntax (code 3) or anything else (code 5).  It was never safe to assume that code 3 meant the device was already the expected size as other problems also cause that same code.  An error is an error and nothing should be relying upon the distinction between these two codes as there are various different possible causes of each.  'lvconvert' is another case being reviewed where previously accepted (but ambiguous or misleading) syntax is now being rejected outright.

We're working towards making fine-grained error codes available in future (which would be tightly-defined and supported), and the 7.3 release contains the first part of this - if operating on several objects at once in a single command, you can now find out which ones triggered the error and which were accessed OK without having to process each separately as you used to have to do.
Comment 9 Zdenek Kabelac 2016-08-16 09:29:23 UTC 
> Can you point me to the lvm bug about "fixing" the error code when extending
> an lv?
>

Here is related bug 1354396.
Comment 10 Stef Walter 2016-08-16 15:00:17 UTC 
Marius, does this affect cockpit, storaged, and their usage of lvresize?
Comment 11 Marius Vollmer 2016-08-17 07:01:22 UTC 
(In reply to Stef Walter from comment #10)
> Marius, does this affect cockpit, storaged, and their usage of lvresize?

No, any non-zero exit code is treated the same.
Comment 12 Yaniv Lavi 2016-08-24 23:11:25 UTC 
We are merged fixed for this regression and we expect that we will be able to backport them in time for RHEL 7.3 support in RHEV. Closing.
Comment 13 Jonathan Earl Brassow 2016-10-27 17:43:38 UTC 

*** This bug has been marked as a duplicate of bug 1354396 ***
Note You need to log in before you can comment on or make changes to this bug.