[libvirt] [PATCH] qemu: Try multiple times to open unix monitor socket

[Jim Paris]

Daniel P. Berrange wrote:
> On Wed, Jul 15, 2009 at 11:40:42AM +0200, Daniel Veillard wrote:
> > On Tue, Jul 14, 2009 at 06:22:42PM -0400, Cole Robinson wrote:
> > > Unlike the pty monitor (which we know exists since we scrape its path from
> > > stdout), we have no way of knowing that the unix monitor socket should exist/
> > > be initialized. As a result, some of my KVM guests randomly fail to start on
> > > F10 host.
> > > 
> > > Try to open the unix socket in a 3 second timeout loop. Ignore EACCES (path
> > > does not exist if a first time run) and ECONNREFUSED (leftover socket from
> > > a previous run hasn't been removed yet). Fixes things for me.
> > 
> >   It's always a bit annoying to end up with heuristics like this
> > but if we don't have any other way, okay, ACK
> 
> I don't like it much either, but this is no worse than what we had todo
> to find the /dev/pts/XXX path where we waited ina  loop for 3 seconds.
> ACK to this patch
> 
> 
> Long term we'll need to discuss with QEMU developers to find a better
> way todo this without needing a timeout.  One idea is actually instead
> of passing a UNIX domain socket path to QEMU, actually create & bind
> the socket in libvirt and then pass the pre-opened FD to QEMU. This
> would guarentee that we can instantly connect to the monitor. Of course
> then the job of waiting passes to the code that sends monitor commands.

What about qemu's -daemonize option:

-daemonize 
   Daemonize the QEMU process after initialization.  QEMU will not
   detach from standard IO until it is ready to receive connections on
   any of its devices.  This option is a useful way for external
   programs to launch QEMU without having to cope with initialization
   race conditions.

It looks like it was introduced in 0.9.0.

-jim