Re: [libvirt-users] Libvirtd freezes

2017-05-03 8:56 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com&gt;: > On 05/01/2017 09:57 AM, Stefano Ricci wrote: >> 2017-05-01 7:32 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com&gt;: >>> On 04/30/2017 07:12 PM, Stefano Ricci wrote: >>> >>>> >>>> The version used for backtrace is 3.2.0, now I have also tried the >>>> current downloaded with git but the problem is always present. >>>> This is the current version log file, set as shown on the DebugLogs page: >>>> >>>> https://drive.google.com/open?id=0By9lwQyveHENdEt4aEtZcUV3ZEU >>> >>> Couple of my findings: >>> >>> 2017-04-30 16:19:34.894+0000: 870: debug : virDriverLoadModuleFile:49 : Load module file '/usr/lib/libvirt/storage-backend/libvirt_storage_backend_rbd.so' >>> 2017-04-30 16:19:35.324+0000: 870: debug : virDriverLoadModuleFunc:71 : Lookup function 'virStorageBackendRBDRegister' >>> >>> it takes nearly .5s to load libvirt_storage_backend_rbd.so >>> >>> But apart from that there is nothing unusual in the logs. So how do you observe the hang? How long it is anyway - assuming it goes away after some time. Or does it hang indefinitely? >>> >>> BTW: is this all the debug messages you have? Because in there, the last line is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. I'd expect libvirt setting qmp_capabilities on the monitor at least. >>> >>> Michal >> >> Virtlib logs end in the way you see, only when i kill the qemu process >> then it starts logging and it is possible to connect remotely with >> virsh. > > I see. There's nothing suspicious in the logs. The fact that libvirt > waits for qemu suggests that qemu did not go daemon. I mean, we pass > -daemonize to qemu, but that doesn't work. I wonder if we cannot do what > we are doing usually when spawning qemu processes: fork() + exec() > instead of relying on -daemonize which is broken. > > BTW: you can verify that qemu did not deamonize itself by consulting the > libvirtd log: > > 2017-04-30 16:19:36.633+0000: 886: debug : virCommandRunAsync:2451 : > Command result 0, with PID 962 > > This means, that PID 962 is qemu. However, when going daemon double fork > is needed, therefore 'pgrep qemu' should print different number than > 962. But I guess it doesn't, does it? > > Michal Fixed, the problem was qemu with the device (I saw that in certain conditions there was segmentation fault)), I recompiled with the correct configuration and now everything works, thanks for the availability, patience shown. Thanks again.