2

I've gotten netconsole setup on a server that's been having a variety of kernel panics lately and I'm trying to log kernel messages to another server. I've tested netconsole after setting it up on the host server by start a netcat session and typing in some random bits of data. These arrive on the capturing server without any issue and I'm able to view the text in the log file I have setup.

However, nothing that is being logged in dmesg (i.e. kernel messages) is being forwarded to the capturing server. My printk is set to 6 1 4 7 (I've gone up to 8 1 4 7 as well) and nothing. I've tried enabling/disabling modules with modprobe and get no output to the capturing server.

Any advice on this would be appreciated as I'm not certain of what else to check at this point since everything is apparently setup correctly.

Striketh
  • 21
  • 1
  • 3
  • I've just had the similar problem. The solution was to specify the netconsole parameter in a correct way. This is how it worked for me `netconsole=@192.168.173.155/,@192.168.173.150/`. It's with the default ports, src-dev and without tgt-mac. – Grigory Oct 17 '14 at 09:55

1 Answers1

2

You say you've tested netconsole by setting it up on the host server. Do you mean you set up a listening syslogd there, and used netcat on the client to send messages to it? If yes, then it doesn't seem like you actually tested netconsole.

Have you verified the netconsole setup, with all mac addresses being correct? The documentation is nice and detailed. Once you've loaded the module with the appropriate attributes, you can test it by writing to /dev/kmsg as root:

# echo my kernel message > /dev/kmsg

Alternatively, trigger a memdump or crash with sysrq. Netconsole should pick this up and send it to your target. Tcpdump is very useful to verify what sort of packets are sent out while you test. Something like this would get you started (notice -e, which will include ethernet addresses):

# tcpdump -i eth0 -n -e port 514

You mention that you want to capture panics. The nature of these panics could be such that they completely kill the system before netconsole (or kexec/kdump) is able to do anything at all (as was the case for the recent leap second issues), or you could indeed get successful log entries.

On a side note, an alternative to netconsole is to use the kexec+kdump kernel facilities. Upon "manageable" panics, the kernel will kexec a kdump-enabled kernel which will load a minimal initrd, and then write the kernel dump to disk. It can then later be analyzed by tools such as crash.

svenx
  • 406
  • 3
  • 4