Re: [Xen-devel] libxl: error handling before xenstored runs

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2011-02-09 at 17:39 +0000, Gianni Tedesco wrote: 
> On Wed, 2011-02-09 at 15:54 +0000, Christoph Egger wrote:
> > On Wednesday 09 February 2011 16:52:08 Christoph Egger wrote:
> > > On Wednesday 09 February 2011 16:42:21 Kamala Narasimhan wrote:
> > > > >>> I'm currently on c/s 22834. Which c/s added the check you are 
> > > > >>> talking
> > > > >>> about?
> > > > >>
> > > > >> http://xenbits.xen.org/staging/xen-unstable.hg?rev/eefb8e971be5
> > > > >
> > > > > This is c/s 22806. So my tree is new enough.
> > > >
> > > > Right, but did you happen to check how you got past the check done by
> > > > that patch for the case in question?
> > >
> > > The pid file simply doesn't exist.
> > 
> > Oh wait. Hit the 'send' button too fast.
> > 
> > The pid file does exist from previous boot.
> 
> Bleh, precisely my problem with these heuristic checks. It's worse on my
> box because if this happens I end up with unkillable xl processes due to
> libxenstore wanting to open /dev/xen/xenbus or whatever it is.

That's the underlying bug which the heuristic is trying to avoid...

Fundamentally the xs ring protocol is missing any way to tell if someone
is listening on the other end so you have no choice but to try
communicating and see if anyone responds.

It's a pretty straightforward bug that the kernel does the waiting to
see if anyone responds bit with an uninterruptible sleep. I took a quick
look a little while ago but unfortunately it didn't look straightforward
to fix on the kernel side :-( I can't remember why though.

It might be simpler to support allowing the userspace client to
explicitly specify a timeout. I'm not sure what the impact on the ring
is of leaving unconsumed requests on the ring when the other end does
show up. Presumably the kernel driver just needs to be prepared to
swallow responses whose target has given up and gone home.

Maybe we should add an explicit ping/pong ring message to the xs ring
protocol?

Ian.

> 
> Gianni 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel