On 01/13/2012 03:19 PM, berrange(a)redhat.com wrote: Aargh - daemon-conf failed again. It feels like on a heavily-loaded machine, our SIGINT is arriving prior to the just-spawned daemon having a chance to register its own handler. I'm wondering if we could make the test more robust by doing some variant of 'virsh -c test:///default connect', while forcing it to connect to the socket we just created, before issuing the kill; on the grounds that if startup took longer than normal, at least the fact that virsh was able to connect means that it is far enough along to accept SIGINT gracefully. Meanwhile, in looking at the test, I realized that libvirtd --timeout isn't very useful in a default installation - that's because the timeout is never hit if there is active state, but the fact that we install an automatic virStoragePool 'default' means that there is always active state. Should we change libvirtd.c:daemonShutdownCheck to merely check whether there are active client connections, rather than its current check of whether there are any active libvirt objects? That is, we don't want the daemon to shut down while there are active connections, but I don't see why active libvirt objects should keep the daemon alive, since we've already gone to great lengths to make sure that active objects persist over a libvirtd restart. That is, letting --timeout force a daemon shutdown when there are active objects but no active connections, and then restarting the daemon later when we want a connection again, should see no difference (the new daemon will reconstruct the same active objects) compared to leaving the daemon alive the whole time because of the active objects. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org