Red Hat Bugzilla – Bug 785148
Lastest updated version is occasionly missing to confirm dm transaction
Last modified: 2015-01-04 21:49:58 EST
Description of problem: FOr some unknown reason udev 179 is now behaving differently on my rawhide. Running lvm2 test suite is getting blocked, because udev is not sending dmsetup udevcomplete operation for udev transaction. Downgrade to udev-175 version and restart of udev service immediately fixes the problem. Before I'll start to look in more depth for this issue - isn't there some trival obvious problem in latest udev release. This problem basically makes lvm tool highly unreliable, since lvm command stays blocked on semaphore and waits until user runs dmsetup udevcomplete_all. Version-Release number of selected component (if applicable): udev-179 How reproducible: Steps to Reproduce: 1. Easiest - run lvm2 tests 2. 3. Actual results: Expected results: Additional info:
There is nothing that immediately comes to mind, which could have caused this. But we have a report from somebody else, who has seen something similar on its own distro. So it's likely some real issue to solve, caused by some change in the most recent udev versions. The lvm test suite does not load kernel modules and depends on child events which the modprobe creates, right? Any hint if we run into a timeout in udev, which gets logged, or do we just miss to trigger the completion for lvm?
As a simple test case that triggers this issue - I've been just using this: create VG test and run following while loop: while :; do lvcreate -L1M -n LV test ; lvcreate -s test/LV -L1M -n testsn ; lvremove -ff test; done Within few iterations the lvm command locks itself waiting on semaphore - so just running dmsetup udevcomplete_all will go forward until next lock. (You could attach gdb to such waiting process to see where it is waiting).
I think I found it. It looks like a udev - devtmpfs interaction which shows up in the recent udev versions: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=NEWS;hb=HEAD Here are new rawhide packages: http://people.freedesktop.org/~kay/fedora/ (I'll update rawhide in a few days, the package is is currently blocked by the f17-usrmove testing) Thanks!
OK, it seems it's not reproducible anymore and it's fixed. Thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This apparently got fixed, as per comment #4. CLosing.