[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output



On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for 
> getting output"):
> > On 11/08/16 18:51, Wei Liu wrote:
> > > I'm pretty out of idea here.
> > 
> > Because of XTF's behaviour (waiting for xenconsoled to catch up), you
> > know for certain that once `xl create` has finished, nothing more will
> > write into the log.
> 
> You're missing the problem, I think.  It's this possible race:
> 
>    VM prints last output to ring
>                                         xenconsoled wakes up from poll
>    VM calls shutdown
>              xenstored sends domain death event
>              xl receives domain death event
>              xl tears down guest, destroying
>                  all relevant xenstore nodes
>              xl exits
>                      xtf-runner opens logfile
>                      xtf-runner reads logfile
>                      xtf-runner gets eof on logfile
> 
>                                        xenconsoled reads data from
>                                        ring (which page is now only
>                                        owned by xenconsoled)
> 
>                                        xenconsoled writes final data
>                                        to logfile
> 
> Wei: Maybe you could rely on `xl console' not exiting until xenconsole
> has written the last data to the logfile ?  You say:
> 
> > It is sure that xenconsoled will close the tty before closing the file,
> > so stat'ing the actual device node won't work either.
> 
> We don't care when xenconsoled closes the logfile.  We care about when
> it last calls write() (with a nonempty buffer).
> 

In logfile mode, no console client is spawned, because it is not
reliable -- that's why we use logfile mode in the first place.

And I would rather just add a bodge (wait 1 or 2 seconds) than to rely
on sophisticated hack.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.