Bug#663931: Same problem
Jim Paris
jim at jtan.com
Sat Apr 21 21:24:20 UTC 2012
I'm having the same problem here. udev seems to have problems after
libvirtd starts (even after libvirtd exits). This in turn causes
problems with virt-manager.
# /etc/init.d/udev stop
Stopping the hotplug events dispatcher: udevd.
# /etc/init.d/udev start
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
# time udevadm settle
real 0m0.262s
user 0m0.000s
sys 0m0.004s
# libvirtd -v
2012-04-21 20:50:01.643+0000: 16223: info : libvirt version: 0.9.11
^C
# time udevadm settle
real 2m0.159s
user 0m0.004s
sys 0m0.016s
#
Note that just starting, then stopping libvirtd, causes udevadm settle
to suddenly take 2 minutes. Even with libvirtd no longer running, and
udevadm settle will now always take 2 minutes until it is restarted.
In "udevadm monitor", starting libvirtd results in:
KERNEL[511713.149926] add /devices/virtual/net/lo/queues/rx-0 (queues)
KERNEL[511713.149960] add /devices/virtual/net/lo/queues/tx-0 (queues)
UDEV [511713.151394] add /devices/virtual/net/lo/queues/tx-0 (queues)
UDEV [511713.151427] add /devices/virtual/net/lo/queues/rx-0 (queues)
KERNEL[511713.224143] remove /devices/virtual/net/lo/queues/rx-0 (queues)
KERNEL[511713.224167] remove /devices/virtual/net/lo/queues/tx-0 (queues)
UDEV [511713.224610] remove /devices/virtual/net/lo/queues/rx-0 (queues)
UDEV [511713.225180] remove /devices/virtual/net/lo/queues/tx-0 (queues)
In syslog output after "udevadm control --log-priority debug",
starting libvirtd results in:
Apr 21 16:56:51 p udevd[17521]: udevd message (SYNC) received
Apr 21 16:56:53 p udevd[17521]: seq 7530 queued, 'add' 'queues'
Apr 21 16:56:53 p udevd[17521]: seq 7530 forked new worker [18181]
Apr 21 16:56:53 p udevd[17521]: seq 7531 queued, 'add' 'queues'
Apr 21 16:56:53 p udevd[18181]: seq 7530 running
Apr 21 16:56:53 p udevd[17521]: seq 7531 forked new worker [18183]
Apr 21 16:56:53 p udevd[18183]: seq 7531 running
Apr 21 16:56:53 p udevd[18183]: passed -1 bytes to netlink monitor 0x1ff6730
Apr 21 16:56:53 p udevd[18181]: passed -1 bytes to netlink monitor 0x2006750
Apr 21 16:56:53 p udevd[17521]: seq 7530 done with 0
Apr 21 16:56:53 p udevd[18183]: seq 7531 processed with 0
Apr 21 16:56:53 p udevd[17521]: seq 7531 done with 0
Apr 21 16:56:53 p udevd[18181]: seq 7530 processed with 0
Apr 21 16:56:54 p udevd[17521]: seq 7532 queued, 'remove' 'queues'
Apr 21 16:56:54 p udevd[17521]: passed 168 bytes to netlink monitor 0x1ff5370
Apr 21 16:56:54 p udevd[17521]: seq 7533 queued, 'remove' 'queues'
Apr 21 16:56:54 p udevd[17521]: passed 168 bytes to netlink monitor 0x1ff5370
Apr 21 16:56:54 p udevd[18181]: seq 7532 running
Apr 21 16:56:54 p udevd[18183]: seq 7533 running
Apr 21 16:56:54 p udevd[18183]: no db file to read /dev/.udev/data/+queues:tx-0: No such file or directory
Apr 21 16:56:54 p udevd[18181]: no db file to read /dev/.udev/data/+queues:rx-0: No such file or directory
Apr 21 16:56:54 p udevd[18181]: passed -1 bytes to netlink monitor 0x2006750
Apr 21 16:56:54 p udevd[18181]: seq 7532 processed with 0
Apr 21 16:56:54 p udevd[17521]: seq 7532 done with 0
Apr 21 16:56:54 p udevd[18183]: passed -1 bytes to netlink monitor 0x1ff6730
Apr 21 16:56:54 p udevd[18183]: seq 7533 processed with 0
Apr 21 16:56:54 p udevd[17521]: seq 7533 done with 0
udevadm settle is eventually just timing out. Looking into why:
# cat /sys/kernel/uevent_seqnum
7534
# od -N 2 -t d2 /dev/.udev/queue.bin | head -1
0000000 7533
So there was another event 7534 that udev never saw, and that's
causing settle to time out. Weird. Maybe a kernel bug?
Running "udevadm monitor --kernel --property" in parallel to those
previous commands shows events up to 7533, but not 7534. And
if I run libvirtd again, it will jump right to 7535.
I'll try to debug this more when I get a chance..
-jim
More information about the pkg-lvm-maintainers
mailing list