Bug 656240 - [RFE] Meaningful error codes from the lvm utility
Summary: [RFE] Meaningful error codes from the lvm utility
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: pre-dev-freeze
: 7.3
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
Depends On: 654691
Blocks: 756082
TreeView+ depends on / blocked
Reported: 2010-11-23 10:22 UTC by Saggi Mizrahi
Modified: 2021-09-03 12:54 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2016-01-18 23:39:44 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Saggi Mizrahi 2010-11-23 10:22:15 UTC
Description of problem:

We need lvm to return meaningful error codes

When creating a PV we get:

Fatal error while trying to detect swap signature on /dev/mapper/14f504e46494c45003430363342552
d6c3159732d6d414447\n  Device '/dev/mapper/14f504e46494c45003430363342552d6c3159732d6d414447' has been left open.

In our environment we need to remove the dead links in this scenario and we want to do it automatically and cannot rely on text parsing.

Comment 4 Alasdair Kergon 2010-11-30 19:39:18 UTC
We're gradually introducing errno use internally for liblvm to report - eventually every 'log_error()' will set an errno. That's a long-term change.  I'm sure we can think up some mechanism to expose these through the command line interface too.  

There might be alternative ways to handle specific cases earlier.

Also, any "device has been left open" message is a bug that should be fixed.  So there are probably three separate issues on this bz.  Using it for the long-term errno change.

Comment 5 Alasdair Kergon 2010-11-30 20:16:37 UTC
Another option: Dave, Peter (and others), would /usr/include/sysexits.h give us enough flexibility instead of using the errno.h range, or are those codes still too generic?

Comment 6 Alasdair Kergon 2010-11-30 20:19:24 UTC
Or we could say 'if it exits with status code EX_OSERR, the last line written to stderr was in a known easy-to-parse format beginning with the internal errno'.

Comment 8 Sayan Saha 2011-05-26 19:18:23 UTC
Based on current priorities we can't accommodate this request in RHEL 6.2. Moving to RHEL 6.3 for re-consideration.

Comment 10 RHEL Program Management 2012-07-10 05:58:05 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 11 RHEL Program Management 2012-07-10 23:56:02 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 14 Alasdair Kergon 2015-09-30 21:39:10 UTC
Changes will be considered as part of the ongoing external library development work.

Comment 16 Jonathan Earl Brassow 2016-01-18 23:39:44 UTC
There are no immediate plans to fix this.  It isn't important enough to prioritize on it's own.  It may be addressed by recent reporting additions and other library work, but it doesn't need to be tracked for years and years.

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