Interestingly on OSX, starting libvirtd (1.3.1) indicates it can see the installed QEMU. However, it crashes out shortly afterwards with a weird error: 2016-01-17 22:02:17.159+0000: 18446744073709551615: error : virEventPollRunOnce:648 : Unable to poll on file handles: Bad file descriptor Does anyone know what that might be about, and/or how to capture more meaningful info? :)

On 17 Jan 2016, at 22:10, Justin Clift <justin(a)postgresql.org&gt; wrote: > On 17 Jan 2016, at 22:04, Justin Clift <justin(a)postgresql.org&gt; wrote: > <snip> >> Interestingly on OSX, starting libvirtd (1.3.1) indicates it can see >> the installed QEMU. However, it crashes out shortly afterwards with >> a weird error: >> >> 2016-01-17 22:02:17.159+0000: 18446744073709551615: error : virEventPollRunOnce:648 : Unable to poll on file handles: Bad file descriptor >> >> Does anyone know what that might be about, and/or how to capture more >> meaningful info? :) > > > With debug level logging, although more verbose there's nothing that > seems smoking-gun like. Except maybe this? > > 2016-01-17 22:07:51.008+0000: 18446744073709551615: debug : virEventPollRunOnce:644 : Poll got error event 9 > 2016-01-17 22:07:51.008+0000: 18446744073709551615: error : virEventPollRunOnce:648 : Unable to poll on file handles: Bad file descriptor > 2016-01-17 22:07:51.008+0000: 18446744073709551615: debug : virNetDaemonRun:703 : Loop iteration error, exiting >

> That's with sudo libvirtd -vl, with tls disabled, tcp enabled, and > tcp auth set to none. > > Can post the entire console log output somewhere if that would help, it's > not stupidly long. :) Debug log here, in case it's useful: :) https://justinclift.fedorapeople.org/libvirt131/libvirtd131_osx_crash1.log + Justin -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On 18 Jan 2016, at 14:00, Martin Kletzander <mkletzan(a)redhat.com&gt; wrote: > On Sun, Jan 17, 2016 at 10:16:54PM +0000, Justin Clift wrote: <snip> >>> With debug level logging, although more verbose there's nothing that >>> seems smoking-gun like. Except maybe this? >>> >>> 2016-01-17 22:07:51.008+0000: 18446744073709551615: debug : virEventPollRunOnce:644 : Poll got error event 9 >>> 2016-01-17 22:07:51.008+0000: 18446744073709551615: error : virEventPollRunOnce:648 : Unable to poll on file handles: Bad file descriptor >>> 2016-01-17 22:07:51.008+0000: 18446744073709551615: debug : virNetDaemonRun:703 : Loop iteration error, exiting > > So we're passing invalid FDs to poll() function. I can't think of > anything else than bisection or pausing the process around > vireventpoll.c:644 (the call to poll()) and checking what the FDs point > to, which one is the invalid one and then going back to see how it got > there, what is it, who forgot to delete it and so on. Gah. Sounds like I may need to go and relearn GDB. Not quite sure I'm motivated enough tbh. We'll see... :) > Did this not happen with the release candidates? As far as I know, on OSX people mainly use virsh. eg for connecting to libvirt on Linux/BSD/whatever hosts. So libvirtd support may or may not have been working for a while. I don't know, as I only tested virsh when updating the recent Homebrew port. ;) But last night I had the realisation that libvirtd itself might work too since it functions on the other BSD's. So, took a few minutes to try it out. Without QEMU installed, libvirtd doesn't error out like the above. That only happens when QEMU is around. So, it's related to that somehow. :)

> Does it happen every single start? Yeah, completely reliable. One other weirdness showed up too, probably not related though. Without QEMU installed, when starting up libvirtd with -l enabled (for listening), it exists complaining about missing cert file. That in itself is not surprising... except it happens even when TLS is disabled is in libvirtd.conf. According to the wiki, turning off listen_tls + turning on listen_tcp should stop the need for cert files: http://wiki.libvirt.org/page/The_daemon_cannot_be_started Does that sound like a bug too, or more like the wiki is out of date? :)

+ Justin