From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Wei Liu <wei.liu2@citrix.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
Date: Fri, 12 Aug 2016 10:23:36 +0100 [thread overview]
Message-ID: <20160812092336.GH20641@citrix.com> (raw)
In-Reply-To: <22444.50156.726813.164501@mariner.uk.xensource.com>
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@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-08-12 9:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 14:14 [XTF PATCH v2] xtf-runner: support two modes for getting output Wei Liu
2016-08-11 16:27 ` Ian Jackson
2016-08-11 16:50 ` Wei Liu
2016-08-11 17:17 ` Ian Jackson
2016-08-11 17:21 ` Andrew Cooper
2016-08-11 17:23 ` Wei Liu
2016-08-11 17:51 ` Wei Liu
2016-08-11 17:54 ` Andrew Cooper
2016-08-11 18:29 ` Ian Jackson
2016-08-12 9:23 ` Wei Liu [this message]
2016-08-12 9:51 ` Ian Jackson
2016-08-12 13:28 ` Wei Liu
2016-08-15 10:58 ` Wei Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160812092336.GH20641@citrix.com \
--to=wei.liu2@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.