On Mon, Nov 14, 2005 at 05:31:00AM -0600, Charles Duffy wrote:
> Since this issue was obviously happening only for me, I went looking for
> potential causes specific to my configuration.
>
> My init scripts start xend with trace_start.
>
> I backed this out (to just use "start"), rebooted, and everything came
> up normally. Rebooted again, likewise. Changed it back to trace_start,
> rebooted again, same failure as described in the thread this should be
> attached to. Changed it to start again, works.
>
> So -- for the initial issue, I have a workaround by way of avoiding
> trace_start, but I'd argue that it's quite certainly a bug that
> trace_start has side effects of this variety. Should I file a bug, or
> does someone else have it?
This is showing up intermittently with our regression tests. It seems to be a
race of some sort, which would be consistent with it going away or coming back
when you fiddle with the logging -- all you are doing is changing the timing
of things so that it appears or does not appear.
If you export XENSTORED_TRACE=1 before starting Xend and Xenstored, then you
will get a log file in /var/log/xenstored-trace.log. This information is
interesting to me, because it shows the ordering over time of the store
events, which makes it easier to piece together what's going on.
Also, could you put a line in
/usr/lib/python/xen/xend/server/DevController.py, to log entry into the
hotplugStatus function (the syntax is log.debug("hotplugStatus entered"), and
it goes below the def hotplugStatus(): line).
With these two things together, if you could reproduce the problem and then
send me /var/log/xend.log and /var/log/xenstored-trace.log, this will help me
to track down the problem.
Unfortunately, I cannot reproduce this myself at the moment, so this will be
the quickest way for you to get the problem diagnosed.
Thanks a lot for your help,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home