On Thu, Oct 29, 2009 at 03:29:38PM +0000, Daniel P. Berrange wrote: > On Thu, Oct 29, 2009 at 04:19:47PM +0100, Daniel Veillard wrote: > > On Fri, Oct 23, 2009 at 02:05:39PM +0100, Daniel P. Berrange wrote: > > > The daemonizing code lets the parent exit almost immediately. This > > > means that it may think it has successfully started even when > > > important failures occur like not being able to acquire the PID > > > file. It also means network sockets are not yet open. > > > > > > To address this when daemonizing the parent passes an open pipe > > > file descriptor to the child. The child does its basic initialization > > > and then writes a status code to the pipe indicating either success, > > > or failure. This ensures that when daemonizing, the parent does not > > > exit until the pidfile is acquired & basic network sockets are open. > > > > > > Initialization of the libvirt drivers is still done asynchronously > > > since this may take a very long time. > > > > Hum, on the other hand maybe it's still better to wait until having > > gone though drivers inits, basically this affects boot time or service > > (re) start time, but maybe it's better to give hand when the service is > > actually started and ready to get connections. With the parallel boots > > only services dependant on libvirt may have to wait a long time, and > > maybe it's better that way. > > We used to block on driver initialization, but its not really viable. > It can take a *very* long time - many minutes if auto-starting lots > of VMs. > > By initializing everything except the drivers, apps depending on > libvirt can reliably connect, but their RPC calls won't be processed > until we finish driver init. So we effectively block dependant > things, without impacting on the OS startup process okay then ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list