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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/