Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
On Mar 15, Guido Günther wrote: > There are several places in the code that try to make sure device nodes > of newly plugged devices, created LVs, etc. are already there. Is there > something better than doing a "udevadm settle"? An event-driven design. -- ciao, Marco signature.asc Description: Digital signature
Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
Hi Marco, On Wed, Mar 14, 2012 at 11:19:22PM +0100, Marco d'Itri wrote: > reassign 663931 lvm2 > thanks > > On Mar 14, Ernesto Domato wrote: > > > (about 3 minutes). Then I found running libvirtd on debug mode that it calls > > "udevadm settle" on startup. This command also takes about 3 minutes to > > respond. > Why does libvirtd run "udevadm settle", for a start? > > > Not using LVM doesn't generates this problem. > > > > So, it seems that when libvirtd is started and there's a pool that use LVM > > it > > mess with udev somehow that produce this behavior. > So this looks like a LVM issue. > It is not a udev bug unless you can show that it is. There are several places in the code that try to make sure device nodes of newly plugged devices, created LVs, etc. are already there. Is there something better than doing a "udevadm settle"? Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
On Mar 15, Ernesto Domato wrote: > I'm not saying that there's a bug on udevd but that libvirtd is > probably causing that running "udevadm settle" doesn't respond as > expected when LVM is used on the machine. But I thought that you could > help giving some advice on how we could debug this :-) By looking at the events log and checking which events/processes are still pending while udevadm settle is waiting for them. -- ciao, Marco signature.asc Description: Digital signature
Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
On Thu, Mar 15, 2012 at 14:35, Marco d'Itri wrote: > On Mar 15, Ernesto Domato wrote: > >> I'm inclined to believe that maybe is more a race condition between >> libvirtd and udev (the libvirt-bin package that contains libvirtd > Not "udevd" per se, so this would still be a bug in some package > other than udev. > I'm not saying that there's a bug on udevd but that libvirtd is probably causing that running "udevadm settle" doesn't respond as expected when LVM is used on the machine. But I thought that you could help giving some advice on how we could debug this :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
On Mar 15, Ernesto Domato wrote: > I'm inclined to believe that maybe is more a race condition between > libvirtd and udev (the libvirt-bin package that contains libvirtd Not "udevd" per se, so this would still be a bug in some package other than udev. -- ciao, Marco signature.asc Description: Digital signature
Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
On Wed, Mar 14, 2012 at 19:19, Marco d'Itri wrote: > reassign 663931 lvm2 > thanks > > On Mar 14, Ernesto Domato wrote: > >> (about 3 minutes). Then I found running libvirtd on debug mode that it calls >> "udevadm settle" on startup. This command also takes about 3 minutes to >> respond. > Why does libvirtd run "udevadm settle", for a start? > I don't know about this one but maybe Guido could give some words about this. >> Not using LVM doesn't generates this problem. >> >> So, it seems that when libvirtd is started and there's a pool that use LVM it >> mess with udev somehow that produce this behavior. > So this looks like a LVM issue. > It is not a udev bug unless you can show that it is. > > -- > ciao, > Marco I'm inclined to believe that maybe is more a race condition between libvirtd and udev (the libvirt-bin package that contains libvirtd depends on udev) that involves LVM provoked by libvirtd. This assumption comes from the fact that udev with LVM works without problem when libvirtd doesn't get involved. Let me know what can I do to help debug this issue to find a solution rather than restart udev :-) Thanks. Ernesto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
reassign 663931 lvm2 thanks On Mar 14, Ernesto Domato wrote: > (about 3 minutes). Then I found running libvirtd on debug mode that it calls > "udevadm settle" on startup. This command also takes about 3 minutes to > respond. Why does libvirtd run "udevadm settle", for a start? > Not using LVM doesn't generates this problem. > > So, it seems that when libvirtd is started and there's a pool that use LVM it > mess with udev somehow that produce this behavior. So this looks like a LVM issue. It is not a udev bug unless you can show that it is. -- ciao, Marco signature.asc Description: Digital signature
Bug#663931: [Pkg-libvirt-maintainers] Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
reassign 663931 udev thanks On Wed, Mar 14, 2012 at 12:33:01AM -0300, Ernesto Domato wrote: > Package: libvirt-bin > Version: 0.9.9-3+b2 > Severity: normal > > Hi, I wasn't able to connect to libvirtd with virt-manager due to timeouts. > > Debuging the problem, I found that at startup virt-manager does a > pool-refresh of the > pools defined on libvirt to check for new pools. This command takes too long > to respond > (about 3 minutes). Then I found running libvirtd on debug mode that it calls > "udevadm settle" on startup. This command also takes about 3 minutes to > respond. This looks like a udev issue so reassigning. True increasing udev's debug output to see where it hangs. It might not be udev but a broken rule. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663931: libvirt-bin: libvirtd make "udevadm settle" respond too slow
Package: libvirt-bin Version: 0.9.9-3+b2 Severity: normal Hi, I wasn't able to connect to libvirtd with virt-manager due to timeouts. Debuging the problem, I found that at startup virt-manager does a pool-refresh of the pools defined on libvirt to check for new pools. This command takes too long to respond (about 3 minutes). Then I found running libvirtd on debug mode that it calls "udevadm settle" on startup. This command also takes about 3 minutes to respond. The only way that I found to solve this problem was to restart the udevd process by /etc/init.d/udev restart After that, "udevadm settle" and "virsh pool-refresh server" for example does respond almost instantly. server is the pool that I defined for the virtual images and is a LVM group. Not using LVM doesn't generates this problem. So, it seems that when libvirtd is started and there's a pool that use LVM it mess with udev somehow that produce this behavior. I don't know if this is a problem with libvirtd, udev or LVM and I don't have the sufficient knowledge to debug it. Anything else that you may need to try to resolve this problem let me know and excuse for my english but it's not my native language. Thanks for all. Ernesto -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libvirt-bin depends on: ii adduser 3.113+nmu1 ii gettext-base0.18.1.1-5 ii libavahi-client30.6.31-1 ii libavahi-common30.6.31-1 ii libblkid1 2.20.1-4 ii libc6 2.13-27 ii libcap-ng0 0.6.6-1 ii libdevmapper1.02.1 2:1.02.67-2 ii libgcrypt11 1.5.0-3 ii libgnutls26 2.12.17-2 ii libnetcf1 0.1.9-2 ii libnl1 1.1-7 ii libnuma12.0.8~rc3-1 ii libparted0debian1 2.3-8 ii libpcap0.8 1.2.1-1 ii libpciaccess0 0.13-1 ii libreadline66.2-8 ii libsasl2-2 2.1.25.dfsg1-4 ii libudev0175-3.1 ii libvirt00.9.9-3+b2 ii libxenstore3.0 4.1.2-3 ii libxml2 2.7.8.dfsg-7 ii libyajl22.0.4-2 ii logrotate 3.8.1-1 Versions of packages libvirt-bin recommends: ii bridge-utils1.5-2 ii dmidecode 2.11-5 ii dnsmasq-base2.60-1 ii ebtables ii gawk1:3.1.8+dfsg-0.1 ii iproute 20120105-1 ii iptables1.4.12.2-1 ii libxml2-utils 2.7.8.dfsg-7 ii netcat-openbsd ii parted 2.3-8 ii qemu-kvm1.0+dfsg-9 Versions of packages libvirt-bin suggests: pn policykit-1 0.104-2 pn radvd -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
