On 08/25/2011 11:36 PM, Daniel P. Berrange wrote:
On Thu, Aug 25, 2011 at 10:07:36PM +0800, Guannan Ren wrote:
> The value of nrequests should always be zero or positive
> but in the case of stream, when error occurrs, it could be negative
> and makes the client socket fd neither writable nor readable. The
> case will lead to hang on libvirt client side.
> This patch aim to fix the problem.
What is the scenario you use to demonstrate the original problem ?
IMHO the fix below is not right, because it is merely patching
up the problems caused by the bug, rather than actually fixing
the bug.
The scenarios is just like the python scripts did, sometimes maybe
we need to monitor and control the stream all the time without quit
on the client side,
other than quit like what libvirt-client did when guest was off. So
I think libvirtd should
support it.
According the log and code, I noticed when the guest is shutting down,
on the server side, the libvirtd will receive two messages from the
pty opened fd,
one is the null string, the other is an error message.(sometime,
only null string,
without error message the case happened on one of boxes ). The null
string is with
type VIR_NET_STREAM and status VIR_NET_CONTINUE, but the error message
is of type VIR_NET_STREAM and status VIR_NET_ERROR that this will
lead to
client->nrequests-- in virNetServerClientDispatchWrite(). so when
the guest
shut down at the second time, the value of nrequests will become -1
on the
assumption that only one thread connecting on client side at that
time.
The negative value will pass over the value assignment to
client->rx and
lead the mode of socket fd to zero, the client side hangs.
One the libvirt-client side, when it meets the null string, it
calls virConsoleShutdown()
then quit and ignore the error message.
I don't know if it is reasonable to fix the problem, any idea is
appreciated.
Guannan Ren