Date: Mon, 31 Dec 2007 00:28:03 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Andrey Chernov <ache@nagual.pp.ru> Cc: current@FreeBSD.ORG Subject: Re: Q&A on textdumps Message-ID: <20071231002207.I21364@fledge.watson.org> In-Reply-To: <20071230210946.GA58498@nagual.pp.ru> References: <20071230130940.T98172@fledge.watson.org> <20071230210946.GA58498@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Dec 2007, Andrey Chernov wrote: > On Sun, Dec 30, 2007 at 01:11:29PM +0000, Robert Watson wrote: > >> I've received a few textdump-related questions that I thought I'd share my >> answers to. > > In case I have remote machine with console unavailable, is it will be enough > to use KDB_UNATTENDED and debug.ddb.textdump.pending=1 in /etc/sysctl.conf > to get automatical unattended textdumps with auto-reboot? It depends whether you want to gather information using DDB output capture or not. If you do the above, you should get a textdump (although I've not tried it), but because there's no scripted DDB output, you won't get extended debugging information. The configuration I'm using is to use a script like the following: ddb script kdb.enter.panic="textdump set; capture on; show pcpu; bt; show locks; ps; alltrace; show lockedvnods; show alllocks; capture off; call doadump; reset" This will give you a textdump on panic, but other ways over entering DDB will just drop to the debugger normally. You might find you want to set a kdb.enter.default script along the above lines, and provide no-op scripts for serial/console break and sysctl in order to drop to the debugger only for cases where the sysadmin has intervened. It might be that, in light of DDB scripting and textdumps, we want to rethink the way KDB_UNATTENDED works, or at least how it behaves in the presence of defined scripts. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071231002207.I21364>