[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Re: Libvirt PHP binding



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]