parted calls 'udevadm settle' after every change causing it to hang for 180s if no udevd with matching magic key is running.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OEM Priority Project |
Fix Released
|
High
|
Al Stone | ||
parted (Ubuntu) |
Fix Released
|
Medium
|
Colin Watson | ||
Lucid |
Fix Released
|
Medium
|
Colin Watson | ||
Maverick |
Fix Released
|
Medium
|
Colin Watson |
Bug Description
parted can take a very long time when run within a chroot.
The issue here is an interface mismatch between udevd and udevadm.
'udevadm settle' works by sending a netlink message to the udevd process. However, the magic key (UDEV_MONITOR_
Development branch: Fixed in parted 2.3-4ubuntu2 by not calling 'udevadm settle' if we're chrooted.
TEST CASE: I verified this by debootstrapping both a lucid and a maverick chroot on a maverick host. In a pristine host config:
chroot /chroot/lucid udevadm settle -> hang
chroot /chroot/maverick udevadm settle -> no hang
If I modify the host's udev to listen to lucid's UDEV_MONITOR_MAGIC define, I get the inverse results.
So how does live-helper trigger this? parted has an ubuntu-specific patch that calls 'udevadm settle' after manipulating partitions to avoid races with other applications that might be triggered by partition changes.
tags: | added: patch |
tags: | added: oem-services |
description: | updated |
Changed in udev (Ubuntu): | |
assignee: | Canonical Foundations Team (canonical-foundations) → Colin Watson (cjwatson) |
description: | updated |
description: | updated |
tags: |
added: verification-done removed: verification-needed |
Changed in parted (Ubuntu Lucid): | |
assignee: | nobody → Colin Watson (cjwatson) |
importance: | Undecided → Medium |
milestone: | none → ubuntu-10.04.3 |
status: | New → Triaged |
Changed in oem-priority: | |
status: | Confirmed → In Progress |
Changed in parted (Ubuntu Lucid): | |
status: | Triaged → In Progress |
tags: |
added: verification-done removed: verification-needed |
Changed in oem-priority: | |
status: | Incomplete → Fix Released |
tags: | added: testcase |
The issue here is as actually an interface mismatch between udevd and udevadm.
'udevadm settle' works by sending a netlink message to the udevd process. However, the magic key (UDEV_MONITOR_ MAGIC) udevd uses to communicate w/ udevadm changed between lucid and maverick (presumably due to a non-backwards- compatible interface change). So, if you are running a maverick system and try to run lucid's udevadm in a chroot, there will be no compatible udevd to respond. The long delay is due to a hardcoded timeout default in udevadm - it will wait up to 180s for udevd to signal settle completion.
I verified this by debootstrapping both a lucid and a maverick chroot on a maverick host. In a pristine host config:
chroot /chroot/lucid udevadm settle -> hang
chroot /chroot/lucid udevadm settle -> no hang
If I modify the host's udev to listen to lucid's UDEV_MONITOR_MAGIC define, I get the inverse results.
So how does live-helper trigger this? parted has an ubuntu-specific patch that calls 'udevadm settle' after manipulating partitions to avoid races with other applications that might be triggered by partition changes.
In my opinion, the right place to fix this is in live-helper, since it could use the host's parted (and therefore the host's udevadm) to tweak devices in the chroot.