Re: Q&A on textdumps

On Mon, 31 Dec 2007, Andrey Chernov wrote:

> On Mon, Dec 31, 2007 at 12:28:03AM +0000, Robert Watson wrote:
>> 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.
>
> I agree, we need to do something lightweight in KDB_UNATTENDED mode istead 
> of very hard way you describe above. Could you please inspect/tweak 
> possibility of running script in unattended mode, keeping in mind that 
> console is unavailable and no interactive break to debugger should ever 
> occurse because there is nobody to enter commands?

In principle, we could add a kdb.event.unattended script, which would execute 
in cases where kdb would be entered except that the system is unattended, with 
an automatic reboot afterwards.  I'll have to look at the way that the ddb/kdb 
relationship is structured there.  Is that something like what you had in 
mind?  It would ensure a reboot at the end, regardless of whether a dump was 
produced.

Robert N M Watson
Computer Laboratory
University of Cambridge