Red Hat Bugzilla – Bug 766308
libvirtd does not close all fds opened by virt-install
Last modified: 2012-06-20 02:38:29 EDT
Description of problem: libvirtd does not close all fds opened to install guests by virt-install after virt-install finished installing the guest. Version-Release number of selected component (if applicable): libvirt-0.9.4-12.el6.x86_64 How reproducible: Always. Steps to Reproduce: Fds opened by libvirted before starting installation: # lsof | grep libvirt | wc 102 922 10980 During installation. # lsof | grep libvirt | wc 117 1067 12790 Installation is done using the below command. # virt-install -r 1000 -n sadique-test5 --disk path=/home/images/sadique-test5.img,format=raw,bus=virtio,size=10 --network bridge=br1,model=virtio --os-type=linux --os-variant=rhel6 --vcpus=2,maxvcpus=4 --cdrom=/tmp/rhel-server-5.4-x86_64-dvd.iso After the installation. (we can see that 1 fd is not closed) # lsof | grep libvirt | wc 103 933 11086 After restarting libvirtd immediately. # service libvirtd restart Stopping libvirtd daemon: [ OK ] Starting libvirtd daemon: [ OK ] [root@dhcp210-207 ~]# lsof | grep libvirt | wc 102 922 10980 I have done multiple installations to verify that the one extra fd is associated with virt-install and not by libvirtd for other purposes.
(In reply to comment #0) > I have done multiple installations to verify that the one extra fd is > associated with virt-install and not by libvirtd for other purposes. Can you track down the problem further? Ideally, I would think that this is the kind of BZ for which SEG could submit a patch. It looks like a simple resource leak.
(In reply to comment #0) > Description of problem: > > libvirtd does not close all fds opened to install guests by virt-install after > virt-install finished installing the guest. > > Version-Release number of selected component (if applicable): > > libvirt-0.9.4-12.el6.x86_64 > BTW, it's okay for libvirt-0.9.8-1.el6.x86_64, I haven't found fds leak after virt-install completing installation, so it should be also okay on upstream, although I can't confirm which commit fixed this issue.
Created attachment 546578 [details] before installation
Created attachment 546579 [details] installation
Created attachment 546580 [details] after installation
Created attachment 546585 [details] after restart libvirtd
I can reproduce this with libvirt-0.9.4-23.el6.x86_64. And can't reproduce this with libvirt-0.9.8-1.el6.x86_64. Updated 4 logs of comment 0 from "before installation" to "restart libvirtd" of comment 0.
It seems some patch hasn't been backported into libvirt rpm package of RHEL: commit 7ea2ef4ce82be9574b4e1fb2a90f2f2c8dc84172 Author: Daniel P. Berrange <berrange@redhat.com> Date: Tue Jul 19 14:11:33 2011 +0100 Use a virFreeCallback on virNetSocket to ensure safe release When unregistering an I/O callback from a virNetSocket object, there is still a chance that an event may come in on the callback. In this case it is possible that the virNetSocket might have been freed already. Make use of a virFreeCallback when registering the I/O callbacks and hold a reference for the entire time the callback is set. * src/rpc/virnetsocket.c: Register a free function for the file handle watch * src/rpc/virnetsocket.h, src/rpc/virnetserverservice.c, src/rpc/virnetserverclient.c, src/rpc/virnetclient.c: Add a free function for the socket I/O watches If so, maybe, should open the bug in 6.2.z, then cherry-pick the patch.
(In reply to comment #7) > I can reproduce this with libvirt-0.9.4-23.el6.x86_64. > And can't reproduce this with libvirt-0.9.8-1.el6.x86_64. > > Updated 4 logs of comment 0 from "before installation" to "restart libvirtd" of > comment 0. Moving to POST
Test this bug with libvirt-0.9.9-1.el6.x86_64. 1. Before starting installation: # lsof | grep libvirt | wc 171 1542 17900 2. During installation: # lsof | grep libvirt | wc 185 1676 19793 3. After installation: # lsof | grep libvirt | wc 171 1542 17900 All fds opened by virt-install are closed, so move bug to VERIFIED.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No Documentation needed
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0748.html