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 628450 - File descriptor ... leaked on lvs invocation.
Summary: File descriptor ... leaked on lvs invocation.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.0
Hardware: s390x
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: Corey Marthaler
URL:
Whiteboard:
Depends On: 629274
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-30 05:37 UTC by Caspar Zhang
Modified: 2010-10-14 10:51 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-14 10:51:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
output of storge test in s390x@rhel6 (7.82 KB, text/plain)
2010-08-30 05:37 UTC, Caspar Zhang 		no flags Details
View All

Description Caspar Zhang 2010-08-30 05:37:20 UTC 
Created attachment 441886 [details]
output of storge test in s390x@rhel6

Description of problem:
After checked system info the test failed for the following msg:


File descriptor 5 (pipe:[19791]) leaked on lvs invocation. Parent PID 2975: sh
File descriptor 6 (pipe:[19792]) leaked on lvs invocation. Parent PID 2975: sh
File descriptor 7 (pipe:[19795]) leaked on lvs invocation. Parent PID 2975: sh
File descriptor 8 (pipe:[19793]) leaked on lvs invocation. Parent PID 2975: sh
File descriptor 9 (pipe:[19796]) leaked on lvs invocation. Parent PID 2975: sh
File descriptor 11 (pipe:[19797]) leaked on lvs invocation. Parent PID 2975: sh
File descriptor 5 (pipe:[19791]) leaked on pvs invocation. Parent PID 2979: sh
File descriptor 6 (pipe:[19792]) leaked on pvs invocation. Parent PID 2979: sh
File descriptor 7 (pipe:[19795]) leaked on pvs invocation. Parent PID 2979: sh
File descriptor 8 (pipe:[19793]) leaked on pvs invocation. Parent PID 2979: sh
File descriptor 9 (pipe:[19796]) leaked on pvs invocation. Parent PID 2979: sh
File descriptor 11 (pipe:[19797]) leaked on pvs invocation. Parent PID 2979: sh
Error: dasdd is currently in use by LVM.
It cannot be tested. You may need to reinstall.

Version-Release number of selected component (if applicable):
v7-R21 (tested in old releases, same error exists)
kernel-2.6.32-70(snapshot-13) (tested in older snapshots, same error exists)

How reproducible:
100%

Steps to Reproduce:
1. run storage test in v7 test suite
2.
3.
  
Actual results:
FAIL

Expected results:
PASS

Additional info:
Comment 1 Rob Landry 2010-09-13 17:06:31 UTC 
The issue for the test is...

Error: dasdd is currently in use by LVM.
It cannot be tested. You may need to reinstall.

...in short configuration issue, dasdd has been requested as the target device but that device cannot be used because it is part of an LVM set.  A device which is not part of an lvm or other array is required for the storage test.

I'm not familiar with the other message about lvs/pvs leaking.  Most of v7 is python so I wouldn't expect a .sh bug to be related but it might be.  Should this bug be changed into chasing that issue as there is nothing to do with the LVM/test failure part.
Comment 3 Tom Coughlan 2010-09-15 19:24:26 UTC 
In reply to a similar bug report Zdenek Kabelac  wrote:

"Note - leaked message is basically harmless - it only reports that it was executed from environment which left more opened descriptors than stdin/out/err - this may present security problem - that's why lvm tool report this issue. So effectively it means the problem is in the executing shell which leaves descriptors opened while calling lvm."

I will take this off the 6.0 blocker list and move it to 6.1. 

Caspar, Rob, is there a QE component to assign this to, or should it be closed?
Comment 4 Zdenek Kabelac 2010-09-16 10:07:10 UTC 
(In reply to comment #1)
> The issue for the test is...
> 
> Error: dasdd is currently in use by LVM.
> It cannot be tested. You may need to reinstall.
> 
> ...in short configuration issue, dasdd has been requested as the target device
> but that device cannot be used because it is part of an LVM set.  A device
> which is not part of an lvm or other array is required for the storage test.
> 
> I'm not familiar with the other message about lvs/pvs leaking.  Most of v7 is
> python so I wouldn't expect a .sh bug to be related but it might be.  Should
> this bug be changed into chasing that issue as there is nothing to do with the
> LVM/test failure part.

Python should fix it's lvm executing part and avoid leaving opened file descriptors after fork and before doing any shell execution - assuming shell inherits these descriptors from python.

The last Error message is more serious - you are having probably some resources conflict with usage of  dasdd device and either the test of system configuration needs to be fixed - it does not look like lvm bug, unless there would be some udev race.
Comment 6 Zdenek Kabelac 2010-10-14 10:51:11 UTC 
Closing this bugzilla - as it's not a problem in LVM - reporter probably found another solution for this problem as no reaction has been appended.


Leaked descriptors needs to be resolved in parent shell 
(simplest could be  exec problematic_FD>&-)

dasdd problem needs to be adresed in the testing environment.
Note You need to log in before you can comment on or make changes to this bug.