[libvirt] the POLLHUP envet for a pipe descriptor is the causethat the libvirt_lxc costs 100% cpu usage.

[jj]

I put some debug info here https://bugzilla.redhat.com/show_bug.cgi?id=1005570
It seems something happened in virLXCControllerConsoleUpdateWatch function,
a pipe , the write side broken, so the read side hangup which causes 100% cpu usage.

On my compute , libvirt_lxc started, 3 hours laster, this would occur . 
In early time , under normal situation ,  the debug would print informations on  newHostEvents or newContEvents ,
but then It's going to be crazy ...  no debug information on newHostEvents or newContEvents anymore ,just infinate loop.


I even could not understand what's the meaning of the code ~~  







------------------ Original ------------------
From:  "Daniel P. Berrange";<berrange at redhat.com>;
Date:  Fri, Nov 1, 2013 05:56 PM
To:  "jj zhong"<menghuizhanguo at gmail.com>; 
Cc:  "libvirt-list"<libvirt-list at redhat.com>; 
Subject:  Re: [libvirt] the POLLHUP envet for a pipe descriptor is the causethat the libvirt_lxc costs 100% cpu usage.



On Fri, Nov 01, 2013 at 09:04:09AM +0800, jj zhong wrote:
> I found the poll in virEventPollRunOnce (vireventpoll.c),  a POLLHUP event
> occurred for a pipe descriptor,  thus the poll always returned because of
> it.( the pipe broken). this may be the best I could track temporarily，I
> don't know what to do netx , to mask the hangup event or to do something to
> handle the hangup event , what to do ?   Is it a bug or something ?

Obviously there is a bug, since we should never go 100% CPU burn. We are
already handling POLLHUP though - it gets mapped to VIR_EVENT_HANDLE_HANGUP

Not sure why we continue to burn cycles though.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131101/0aeb62a2/attachment-0001.htm>