On Wed, Jul 15, 2009 at 09:49:03AM -0400, Jim Paris wrote:
> 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 p
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
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 mon
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/
> >
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
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. Ig
