2

Is there any way to check the number of kernel panic that happened on a system ? If not, any idea on how to do make this new functionality ?

I would like to hear about an answer for most Unix-like systems :)

Antzi
  • 283
  • 1
  • 7
  • 1
    I'm sure most Admins would like it to be 0. What use could you get out of a "count"? Wouldn't you just want to fix whatever caused the panic *if it happens at all*? – Chris S Jun 07 '13 at 14:06
  • 1
    @ChrisS Of course :) The idea is to make a diagnostic of computer who remained unmonitored for long time, and to make simple statistics. Plus, sadly, some kernel panic can be hard to fix (Especially if linked with a hardware problem). – Antzi Jun 07 '13 at 14:09
  • 1
    @Antzi ***You're Doing It Wrong***. We don't *count* panics, we *fix the cause* (by working with the kernel developers or replacing the defective hardware). The only "diagnostic" should be taking a copy of the memory dump from the system for analysis. – voretaq7 Jun 07 '13 at 16:18

2 Answers2

2

You could take a look at all the /var/log/message files and count the number of reboot specific headers. Since one generally reboots after a kernel panic.

mdpc
  • 11,698
  • 28
  • 51
  • 65
2

If you configure kdump

  Kdump is a kexec based crash dumping mechansim for Linux. 
  Kdump functionality is broken mainly in two components, user space and kernel space.    
  Kernel space patches are already part of main line kernel tree. 
  User space component is nothing but a patch on top of existing kexec tools.

you could configure a kdump_post script in /etc/kdump.conf to run an arbitrary script to increment a number each time you get a panic..

kdump_post <binary | script>

This directive allows you to run a specified executable just after the memory dump     
process terminates. The exit status from the dump process is fed to the kdump_post     
executable, which can be used to trigger different actions for success or failure.

the advantage of that approach is that then you will hace kdump configured too, which can provide valuable information for root cause analyses for kernel panics, even if you are no kernel hacker...

Petter H
  • 3,383
  • 1
  • 14
  • 18