Daniel P. Berrange napsal(a):
On Tue, Apr 14, 2009 at 04:00:18PM +0100, Daniel P. Berrange wrote:
> On Tue, Apr 14, 2009 at 03:56:28PM +0200, Radek Hladik wrote:
>> When running from command line everything seems to work fine. This is of
>> course singlethreaded and potential resource leaks need not to cause a
>> problem. However when running from webserver, the result is much more
>> interesting. When connecting to qemu:///system (via local socket) using
>> <?
>> libvirt_connect($uri,true);
>> ?>
>> I can crash the libvirt daemon after cca 10 page reloads - sometimes
>> with message
>> Apr 13 15:32:44 kvmtest kernel: libvirtd[8263]: segfault at 4 ip
>> 00000039d7223fc0 sp 00007fa6fbc29a88 error 6 in
>> libdbus-1.so.3.4.0[39d7200000+3c000]
>> in system log, sometimes without any message.
> Crashing the libvirtd daemon is not your fault ! It is supposed to be
> completely robust against whatever bad stuff the client may throw at
> it. So even if the client has a bug, then it shouldn't crash the daemon.
>
> If possible it'd be helpful if you can get a stack trace from the daemon.
> You can do this by stopping the demon '/etc/init.d/libvirtd stop' and
> then running it under GDB directly
>
> 'gdb /usr/sbin/libvirtd'
>
> make sure you have libvirt-debuginfo RPM installed if using Fedora, or
> have built with '-g' debug option if built manually.
Actually now that I remember, there were a definitely a couple of
libvirtd crashing bugs in the 0.6.0 release. So well worth upgrading
before trying to debug this in any detail
I upgraded to libvirt 0.6.2 from rawhide - I had to compile it from SRPM
because RPM version reported some selinux undefined symbol. But my test
system is hybrid of F10, F11 and rawhide :-).
On the first view things looks a lot better now. When connecting locally
I have not been able to crash the daemon for cca 100 reloads and when
connecting via qemu+tcp the count of open pipes seems to be constant. I
have cca 15 httpd processes running and they have total 42 handles to
pipes open and there are only two unique pipe numbers. This number did
not change for last cca 30 minutes. I am watching this in /proc so these
pipes need not to be related to libvirt at all.
I've updated the documentation - added note that version 0.6.2 is
required :-) - and modified the code to refuse to connect when version
is lower that 0.6.2. I've put the modified version to
http://phplibvirt.cybersales.cz/ as v0.2.1 APLHA.
I will test it a little more and I'll see if this version would be safe
to be tested by others.
Radek