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(a)redhat.com>
> ---
>
ACK, all of that is necessary and it also complies with the error
message flag request from v1.