© Giuseppe Ramos, 123RF.com

Creating and evaluating kernel crash dumps

Crash Test

A dump of the operating system kernel as a means of problem analysis is nothing new in the Unix world. However, this topic has been sadly neglected on Linux for a long time. The first attempts were made in 1999 with the Linux Kernel Crash Dump (LKCD) project [1]. This approach originally initiated by SGI was successful in that it made its way into the SUSE Enterprise distribution [2]; however, the problem of writing a dump to an MD RAID or transferring larger kernel images ultimately proved unfixable.

Further attempts with Netdump (Red Hat) or Diskdump [3] in 2002 and 2004 also had only moderate success. Meanwhile, an approach that can be used reliably in production environments comes in the form of kexec and kdump [4]-[7]. A core issue and the biggest challenge in writing kernel dumps is: Who should do it? The obvious answer is surely: the kernel itself. However, this approach, which the LKCD project pursued, involves some risks.

How far can you trust a kernel that just crashed? Are the kernel structures and data intact? Are the drivers still correctly initialized so that the hard drive or the NFS share is accessible? These are exactly the problems that LKCD encountered.

It would be preferable to use an entity outside of the kernel to save the kernel dumps. With the growing proliferation of virtualization, a hypervisor is an obvious candidate for this, and you can use VMware, Xen, or KVM to save a dump of the Linux kernel – but I'll get to that later.

If Linux is running directly on the metal, the hypervisor approach is worthless, which is where kdump – or, more precisely, kexec – enters the game. The kexec tool is a kind of kernel-to-kernel bootloader, and the

Buy this article as PDF

Express-Checkout as PDF

Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES

Print Issues

Digital Issues

 

SUBSCRIPTIONS

Print Subs

Digisubs

 

TABLET & SMARTPHONE APPS

US / Canada

UK / Australia