Gilad Ben-Yossef wrote:

Actually, on a prodction server (or some embedded systems even) what you really want to do in case of a kernel panic is not to reboot , but rather to log the panic and THEN reboot so that you can have a good idea on what caused the problem without booting again and loosing the all important 5 nines uptime.

That's what the Linux Kernel Crash Dump patch and tool does. You can find it here:

http://lkcd.sourceforge.net/

Indeed, one of my main gripes with the so called Enterprise version of Redhat (and others? I don't know) is that they don't include this. Which means that if a client has a crash the only way to know what happened is to re-create the crash. A really bad idea IMHO in a prodcution environment.

Cheers,
Gilad




While defenitely an interesting patch, I find it unnecessary for the trouble I've seen thus far. Most of the panics I've seen on colocated servers were during boot, and due to bad configuration. Not during runtime and due to kernel bugs. As such, such a dump will:
1. Not work (it hasn't found the kernel modules to access the hard disk from initrd, where do you expect it to save the crush dump?)
2. Not help if it did (the problem is usually fairly straightforward to fix, or impossible).


All I really need is "restore to known good", and then ability to retry.

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/


================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]



Reply via email to