On 29.07.2010 20:32, Chris Lalancette wrote:
Ah, OK. So then the question becomes whether the problem is in the ruby
bindings not releasing the object in certain circumstances, or in rails
holding onto the object too long. Unfortunately I'm not really that familiar
with rails or passenger, so I'm not entirely sure how to figure out where the
problem is.
I'll see if I can do a bit of testing and look at object lifetimes from the
point-of-view of ruby-libvirt to try and eliminate that from the equation.
following testcase confirms that problem is in bindings itself:
ree-1.8.7-2010.02 > require 'libvirt'
=> true
ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c
libvirt-sock`
0
=> nil
ree-1.8.7-2010.02 > c = Libvirt::open 'qemu:///system'
=> #<Libvirt::Connect:0x265b718>
ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c
libvirt-sock`
1
=> nil
ree-1.8.7-2010.02 > d = c.lookup_domain_by_name 'abc'
=> #<Libvirt::Domain:0x2705128>
ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c
libvirt-sock`
1
=> nil
ree-1.8.7-2010.02 > c.close
=> nil
ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c
libvirt-sock`
1
=> nil
ree-1.8.7-2010.02 > c.closed?
=> true
ree-1.8.7-2010.02 > d.connection.closed?
=> true
ree-1.8.7-2010.02 > d.create
ArgumentError: Connection has been closed
from (irb):28:in `create'
from (irb):28
from :0
ree-1.8.7-2010.02 > d=nil
=> nil
ree-1.8.7-2010.02 > c=nil
=> nil
ree-1.8.7-2010.02 > GC.start
=> nil
ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c
libvirt-sock`
1
=> nil
Tested with MRI 1.8.7-p302 and ree-1.8.7-2010.02.
My question is how to close connection to libvirtd?
regards,
--
Pawel
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list