Xen devel - Aug 2005 - [PATCH] Add timeout to xenconsole to fix race condition in xm create -c

This should address the problems people are having now.

Wait a little bit for tty to appear.  There is a race condition that 
occurs after xend creates a domain.  Since no event triggers consoled to 
re-examine existing domains, we''ll often not see the new pty by the
time
we''re here.  Since consoled sleeps for 2 second periods, a 5 second 
timeout should keep us covered.

A xenstore watch isn''t much better since we don''t want to
block forever
if given an invalid domain or worse yes, a domain that someone else has 
connected to.

Signed-off-by: Anthony Liguori

Regards,

Anthony Liguori


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

Anthony Liguori wrote:
> This should address the problems people are having now.
> 
Anthony, Hi

It cleanly fixed the problem I had. Thanks a lot for the quick fix!
> Wait a little bit for tty to appear.  There is a race condition that
> occurs after xend creates a domain.  Since no event triggers consoled
> to re-examine existing domains, we''ll often not see the new pty by
> the time we''re here.  Since consoled sleeps for 2 second periods,
a 5
> second timeout should keep us covered.
> 
> A xenstore watch isn''t much better since we don''t want to
block
> forever if given an invalid domain or worse yes, a domain that
> someone else has connected to.
> 
> Signed-off-by: Anthony Liguori
> 
> Regards,
> 
> Anthony Liguori

Jun
---
Intel Open Source Technology Center

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

On 8/30/05, Anthony Liguori <aliguori@us.ibm.com>
wrote:
> This should address the problems people are having now.
> 
> Wait a little bit for tty to appear.  There is a race condition that
> occurs after xend creates a domain.  Since no event triggers consoled to
> re-examine existing domains, we''ll often not see the new pty by
the time
> we''re here.  Since consoled sleeps for 2 second periods, a 5
second
> timeout should keep us covered.
I''ve applied this with slighly changed comments since xenconsoled now
uses watches and should setup the tty almost immediately.  The race
still exists though.
> A xenstore watch isn''t much better since we don''t want to
block forever
> if given an invalid domain or worse yes, a domain that someone else has
> connected to.
It would improve the responsiveness but a timeout is still needed for
the reasons you pointed out.

Finally, there''s still an issue with storing the console tty
information in /console/<domid> -- there might be stale data from a
previous domain having the same domid and the client might run before
the console daemon has rewritten the tty entry.  I think this is best
fixed by moving the console tty information into the domain''s /domain
tree.

    christian

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

Christian Limpach wrote:
>On 8/30/05, Anthony Liguori <aliguori@us.ibm.com> wrote:
>  
>
>>This should address the problems people are having now.
>>
>>Wait a little bit for tty to appear.  There is a race condition that
>>occurs after xend creates a domain.  Since no event triggers consoled to
>>re-examine existing domains, we''ll often not see the new pty by
the time
>>we''re here.  Since consoled sleeps for 2 second periods, a 5
second
>>timeout should keep us covered.
>>    
>>
>
>I''ve applied this with slighly changed comments since xenconsoled
now
>uses watches and should setup the tty almost immediately.  The race
>still exists though.
>  
>
Yes, what we really want is a event-dispatch mechanism.  It''s something
we''ve talked about a bit here but without flushing out any sort of 
actual design.
>>A xenstore watch isn''t much better since we don''t want
to block forever
>>if given an invalid domain or worse yes, a domain that someone else has
>>connected to.
>>    
>>
>
>It would improve the responsiveness but a timeout is still needed for
>the reasons you pointed out.
>
>Finally, there''s still an issue with storing the console tty
>information in /console/<domid> -- there might be stale data from a
>previous domain having the same domid and the client might run before
>the console daemon has rewritten the tty entry.  I think this is best
>fixed by moving the console tty information into the domain''s
/domain
>tree.
>  
>
Rusty had some objections to this originally--this is why its not there 
now.  Rusty?

Regards,

Anthony Liguori
>    christian
>
>  
>

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