Hi LQ,

I'm running a network with several embedded modules running Linux.
They are all controlled by 1 server, connected over a standard LAN network. This server can also take care of updates for the modules.

Whenever something goes wrong, for example after an update, one of the modules can suffer a kernel panic. I would like the module to report this to the server, instead of just panicking away...

So my question:
- would it be possible to edit the panic() function in the kernel source to send an (UDP) message to the server? (supposed it already has acquired an IP address through DHCP) (I do have C programming experience, but no Linux kernel programming experience)
- would it be _wise_ to do so?

Thanks in advance.

It would be possible, but it would be difficult for a novice kernel developer. And being a novice, you would probably use a solution that would introduce instability into the kernel. You might end up creating more panics than you were trying to monitor.

If you want the wise solution, you can easily write a user space application that sends out UDP heartbeat messages. If a machine stops sending out heartbeats, you can assume it is hung. The advantage of this situation is that you potentially capture a wider variety of problems than just kernel panics (e.g. network adapter failure).

Thanks for your reply.

I already have the alive messaging to the server, but I thought it would be useful that the module reported itself as 'panicked'.

That is exactly what I was afraid of :)
I guess I will follow your advice, unless someone else comes up with some useful tips how to do it.

Have you looked at using the "Remote Machine" facility in syslogd (man syslog.conf) to send the panic messages to the server?

Use kexec/kdump utility from
http://www.linux-mag.com/id/2998

OR

http://lxr.linux.no/linux+v2.6.34.1/...kdump.txt#L150

This will reboot the machine to the new kernel and create a /proc/vmcore (kernel dump core). You can write a user space program to send the update in the new kernel saying that the system rebooted with the dump core. Analysing the dump core with gdb OR crash utility will tell you which module created the panic.