Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
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)...
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.
(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 ?
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.
(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.
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.
(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.
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.