On 07.05.2015 16:07, Martin Kletzander wrote: > 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. Thanks, pushed. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list