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=0By9lwQyveHENdEt4aEtZcUV3ZEUCouple 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
2017-05-01 7:32 GMT+02:00 Michal Privoznik <mprivozn@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. > > MichalVirtlib 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. Until the qemu process is active you can not use libvirt. In the following libvirt log file find all that happens when killing the qemu process, after the line 2017-05-01 07:40:47.772+0000: 892: debug : virCommandRunAsync:2451 : Command result 0, with PID 970 https://drive.google.com/open?id=0By9lwQyveHENNVBaczFxNHBCYU0 Stefano
On 05/01/2017 09:57 AM, Stefano Ricci wrote:> 2017-05-01 7:32 GMT+02:00 Michal Privoznik <mprivozn@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