Hide Forgot
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.
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.
(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?
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.
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.
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.
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
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