On 06/24/2011 05:53 AM, Chris Lalancette wrote:
On 06/24/11 - 08:15:41AM, Chris Lalancette wrote:
>> Waiting for F15-x86_64-jeos to finish installing, 49630/50000
>> Waiting for F15-x86_64-jeos to finish installing, 49620/50000
>> ^CLibvirt Domain Info Failed:
>> code is 38
>> domain is 13
>> message is poll on socket failed: Interrupted system call
>> level is 2
>> str1 is %s
>> str2 is poll on socket failed: Interrupted system call
So this error message in libvirt comes from this bit of code:
src/remote/remote_driver.c:remoteIOEventLoop()
repoll:
ret = poll(fds, ARRAY_CARDINALITY(fds), timeout);
if (ret < 0 && errno == EAGAIN)
goto repoll;
...
if (ret < 0) {
if (errno == EWOULDBLOCK)
continue;
virReportSystemError(errno,
"%s", _("poll on socket failed"));
goto error;
}
What is going on here is that the libvirt client library is polling on the
socket(s) that it is using to connect to the libvirtd server. For some reason
that poll call sometimes returns EINTR, leading to the rest of the badness.
>From a quick glance at the kernel, it seems like the only way poll can return
EINTR is when there is another signal already pending either when we enter
poll or after the poll has begun.
I stopped there. It is pretty clear for now that this is a bug in libvirt,
not handling signals properly. I would suggest opening a bug against libvirt
for now, and we can continue there.
It was interrupted because I pressed CTRL-c which sends a signal to the
local process and interrupts the poll call. I pressed ctrl-c after
20-30 minutes.
Don't have any idea of which type of bug to open since it seems to me
that the VM shouldn't have exited normally after install and at the same
time this libvirt call be blocking in poll. Is it typical that the
virtual machine would be destroyed whlie this call trace would be
executing? Probably a bug in libvirt, but also a bug in oz (I'd except
oz would not continue to poll on virtual machine info for virtual
machines that are gone.
Regards
-steve