Bug 785148 - Lastest updated version is occasionly missing to confirm dm transaction
Summary: Lastest updated version is occasionly missing to confirm dm transaction
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: udev-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-27 12:59 UTC by Zdenek Kabelac
Modified: 2015-01-05 02:49 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-01-05 02:49:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Zdenek Kabelac 2012-01-27 12:59:15 UTC
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:

Comment 1 Kay Sievers 2012-01-27 14:42:52 UTC
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?

Comment 2 Zdenek Kabelac 2012-01-27 15:11:16 UTC
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).

Comment 3 Kay Sievers 2012-01-29 05:21:24 UTC
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!

Comment 4 Peter Rajnoha 2012-01-29 09:51:02 UTC
OK, it seems it's not reproducible anymore and it's fixed. Thanks.

Comment 5 Fedora End Of Life 2013-04-03 17:56:24 UTC
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

Comment 6 Lennart Poettering 2015-01-05 02:49:58 UTC
This apparently got fixed, as per comment #4. CLosing.


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