Bug 1211575 - Hanging FDs left over by dmeventd
Summary: Hanging FDs left over by dmeventd
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Marian Csontos
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-14 11:03 UTC by Nenad Peric
Modified: 2019-11-14 06:41 UTC (History)
9 users (show)

Fixed In Version: lvm2-2.02.140-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-11 01:16:30 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0964 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2016-05-10 22:57:40 UTC

Description Nenad Peric 2015-04-14 11:03:25 UTC
Description of problem:

A lot of dmeventd FDs (/dev/mapper/control) remain open after running a test suite. 

Version-Release number of selected component (if applicable):

lvm2-2.02.118-1.el6.x86_64

How reproducible:

Everytime

Steps to Reproduce:

No real simple steps to reproduce for now (will look into it). 
running revolution_9 test suite causes dmeventd to behave this way easilly. 
The problem was ran into while testing the patch for Bug 1130245.

Test which was ran:

/revolution_9 -i 2 -j 1 -w EXT -F -o node-name

Actual results:

Hundreds (in my test 390) open FDs left.

Expected results:

extraneous FDs should be cleaned up and removed.

Comment 2 Nenad Peric 2015-04-14 13:39:10 UTC
Narrowed down to one test which generates these hanging FDs:

./revolution_9 -i 2 -j 1 -w EXT -F -o tardis-02 -e kill_random_legs 

So creating raid devices, having some I/O and killing off legs causes this issue.

Comment 3 Peter Rajnoha 2015-04-14 13:45:59 UTC
(In reply to Nenad Peric from comment #2)
> Narrowed down to one test which generates these hanging FDs:
> 
> ./revolution_9 -i 2 -j 1 -w EXT -F -o tardis-02 -e kill_random_legs 
> 
> So creating raid devices, having some I/O and killing off legs causes this
> issue.

Can you paste exact commands that were run?

Comment 4 Jonathan Earl Brassow 2015-04-15 16:15:05 UTC
that may be difficult, as the test is a looping test designed to stress LVM RAID by doing I/O, killing legs, checking for survival, reviving the devices, and repeating - all while doing 'lvs', 'pvs', and other operations.

It would be nice to know which commands are the ones resulting in the stray FDs.

Comment 5 Marian Csontos 2015-10-16 12:34:12 UTC
Zdenek has made a lot of changes recently. This may well be fixed. I will retest with upstream and either close it or get it fixed.

Comment 6 Zdenek Kabelac 2015-10-29 12:36:58 UTC
New dmevent in lvm2 2.02.133 handles resources in a better way.
Previously there used to be a race on access & close of control fd which may have lead to desctriptor leakage.

Comment 10 Corey Marthaler 2016-02-22 17:41:18 UTC
Marking verified in the latest rpms. I ran many iterations of this test case and never saw more than two or three open FDs during or after the test completed.


2.6.32-615.el6.x86_64
lvm2-2.02.141-2.el6    BUILT: Wed Feb 10 07:49:03 CST 2016
lvm2-libs-2.02.141-2.el6    BUILT: Wed Feb 10 07:49:03 CST 2016
lvm2-cluster-2.02.141-2.el6    BUILT: Wed Feb 10 07:49:03 CST 2016
udev-147-2.71.el6    BUILT: Wed Feb 10 07:07:17 CST 2016
device-mapper-1.02.115-2.el6    BUILT: Wed Feb 10 07:49:03 CST 2016
device-mapper-libs-1.02.115-2.el6    BUILT: Wed Feb 10 07:49:03 CST 2016
device-mapper-event-1.02.115-2.el6    BUILT: Wed Feb 10 07:49:03 CST 2016
device-mapper-event-libs-1.02.115-2.el6    BUILT: Wed Feb 10 07:49:03 CST 2016
device-mapper-persistent-data-0.6.2-0.1.rc1.el6    BUILT: Wed Feb 10 09:52:15 CST 2016
cmirror-2.02.141-2.el6    BUILT: Wed Feb 10 07:49:03 CST 2016

Comment 12 errata-xmlrpc 2016-05-11 01:16:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0964.html


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