On Thu, May 07, 2015 at 11:33:58AM +0200, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=890648 So, imagine you've issued an API that involves guest agent. For instance, you want to query guest's IP addresses. So the API acquires QUERY_JOB, locks the guest agent and issues the agent command. However, for some reason, guest agent replies to initial ping correctly, but then crashes tragically while executing real command (in this case guest-network-get-interfaces). Since initial ping went well, libvirt thinks guest agent is accessible and awaits reply to the real command. But it will never come. What will is a monitor event. Our handler (processSerialChangedEvent) will try to acquire MODIFY_JOB, which will fail obviously because the other thread that's executing the API already holds a job. So the event handler exits early, and the QUERY_JOB is never released nor ended. The way how to solve this is to put flag somewhere in the monitor internals. The flag is called @running and agent commands are issued iff the flag is set. The flag itself is set when we connect to the agent socket. And unset whenever we see DISCONNECT event from the agent. Moreover, we must wake up all the threads waiting for the agent. This is done by signalizing the condition they're waiting on. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> ---
ACK, all of that is necessary and it also complies with the error message flag request from v1.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list