From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Limpach Subject: Re: Re: Timeout connecting to device Date: Wed, 24 Aug 2005 09:25:18 +0100 Message-ID: <3d8eece2050824012547b9bb89@mail.gmail.com> References: <430A387C.2030108@intel.com> <430BCF14.2040409@intel.com> <1124858620.17004.96.camel@localhost.localdomain> Reply-To: Christian.Limpach@cl.cam.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1124858620.17004.96.camel@localhost.localdomain> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Rusty Russell Cc: Arun Sharma , xen-devel List-Id: xen-devel@lists.xenproject.org On 8/24/05, Rusty Russell wrote: > > - is there a way to debug xenstored? It doesn't seem to be logging much= . >=20 > Yes, add --trace-file=3D/tmp/trace to the invocation of xenstored, and > you'll see all the conversations that the store has. You can set XENSTORED_TRACE in /usr/sbin/xend's environment causing it to add the --trace-file option to the invocation of xenstored. You'll need to do this in your boot script because after restarting xenstored, the backends won't notice any new changes anymore. > > - Could we add some debug flags elsewhere as well (xenbus with debug=3D= 1?) > > to make debugging problems of this nature easier? >=20 > The trace file is actually better in my experience. Also look for > "error" nodes in the store (although Christian removed some of those > paths in the merge). I only removed the ones which were not fatal because I was under the impression initally that adding an error node does indicate a final error after which it would be up to a control tool to sort out the failure or report it. christian