There are two parts to this bug.
The actual bug is being caused by "lvm vgscan" opening all block devices
on the system writable and then closing them again, which triggers the
inotify event. There seems to be no reason they cannot be opened
readonly, since the only thing it does is call fstat() and read() on
them.
Since the devices include any LVM PVs (which is what it's looking for),
this gives you a recursive loop where LVM PVs appear to have been
changed, so udev calls "lvm vgscan" again to update its tables.
Part #1 of the fix will be a patch to LVM to only open block devices
with O_RDONLY
Part #2 of the fix will be a patch to udev to not add the inotify watch
until all RUN rules are processed; this will prevent the initial
onslaught on boot, and hopefully guard against anything it runs changing
the device resulting in reprocessing (which is better handled with udev
rules ordering anyway).
It will obviously not protect against a "udevadm trigger" once booted,
so it's possible that we'll trip over this with another program later
and will have to fix that one in the same manner as LVM.
It's not yet clear why this does not affect _everyone_, there appears to
be a race involved as slowing udev down with various log levels - or
using only one core - is enough to hide the bug for some people. I need
to work out why that is before uploading the fixes
** Changed in: lvm2 (Ubuntu Jaunty)
Importance: Undecided => High
Status: New => Triaged
Target: None => jaunty-alpha-5
--
udev repeatedly generates "change" events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
