[libvirt-users] Libvirtd freezes

[Stefano Ricci]

2017-05-03 8:56 GMT+02:00 Michal Privoznik <mprivozn at redhat.com>:
> On 05/01/2017 09:57 AM, Stefano Ricci wrote:
>> 2017-05-01 7:32 GMT+02:00 Michal Privoznik <mprivozn at redhat.com>:
>>> 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.

Stefano