Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!turnkey!jackv From: jackv@turnkey.tcc.com (Jack F. Vogel) Newsgroups: comp.unix.sysv386 Subject: Re: Kernel core dumps (was Re: out of swap space??) Keywords: kernel core dumps crash forced panic Message-ID: <1991May04.132158.17121@turnkey.tcc.com> Date: 4 May 91 13:21:58 GMT References: <1991Apr23.214037.16410@netcom.COM> <1991Apr24.165943.7202@rfengr.com> <450@bartal.BARTAL.COM> <9105031411.aa04050@art-sy.detroit.mi.us> Reply-To: jackv@turnkey.TCC.COM (Jack F. Vogel) Organization: Turnkey Computer Consultants, Westchester, CA Lines: 60 In article <9105031411.aa04050@art-sy.detroit.mi.us> chap@art-sy.detroit.mi.us (j chapman flack) writes: >This reminded me of questions I've been meaning to ask. I never knew where >the kernel core dump goes in a panic (and so far I've had no opportunity to >find out....). This posting suggests it goes in the swap area, but that >brings up an immediate question: Initial point: you say you are running SCO, since I run ISC what follows may or may not apply. I am not sure how close the two systems are in handling panic dumps... > At what point does the kernel begin using the swap area on the next boot?? Sometime before coming up fully multiuser a script is run, /etc/dumpsave, which decides if there is a dump in the swap area and prompts you if you want to save it. You can save either to floppy or tape. If you choose floppy you must have enough formatted floppies to hold it (the size will be approximately your real memory size). If you choose not to save, the kernel will begin using the swap device and the data will be overwritten. > How am I able to use `crash' to examine the core dump before the evidence > is overwritten? Since the swap device is used, there is no way to try to examine the dump prior to saving and reloading it. > It would have been handy to be able to run something as root that >forces a panic, then reboot and analyze the dump while the system is still >reasonably reliable. Again, I can't speak for SCO's implementation, but one way to do this given the AT&T standard is to have the kernel debugger linked into your kernel (see debugger(8)) and then if you want to force a dump, enter the debugger and give a 'sysdump' command. I must emphasize that I have never done this, and given that it dumps all over your swap space I would presume this is fatal to the running system :-} :-}. Or one could just use the debugger to branch the kernel to panic(). The ISC docs have a cryptic 'BUGS' statement about 'sysdump' sometimes not working without any details, perhaps someone at Interactive could comment?? But, in theory at least, this should do what you want. Just for comparison, no commercial plug really intended this is just for an implementation example, AIX on the PS/2 allows you to create a dedicated dump partition where multiple dumps can be stored. This allows you to take "running dumps" of the system which can then be examined with crash at your leisure. Alternately, you can configure the kernel for the dump device to be the floppy, then if you ever panic the system will stop and prompt you if you want to save the dump to insert the floppy, etc... From a serious service point of view this functionality is essential. Of course, this consumes disk space, but its an option if you so desire. Oh yes, there is also a key sequence on the console that lets you force either a running dump or a panic at any particular time. Disclaimer: I don't speak for the company! -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM