The "Kernel Panic Receiver" (or KPR) product is an open-source component of ours, designed to pre-emptively resolve any kernel-related issues. As updating the kernel is one of the most sensitive tasks, we'd like to achieve maximum stability along the way. In case something goes wrong, proactively reacting to kernel crashes helps us tremendously.
On the server-side, the KPR relies on the netconsole module, which is used for logging kernel messages and transmitting them over the network.
You can check the entire announcement in our CL Blog post. In this guide, we cover the frequently asked questions that you could probably wonder about as well.
What data does KPR receive from the server?
The netconsole module sends to KPR the output from dmesg; it does not transfer the entire core dump. Transferring the core dump like that could potentially compromise the security of a sender data.
It's not always enough to have the dmesg output to debug kernel issues. What else is there to do?
We would like to enable the Kdump service by default on servers powerful enough to handle it in future releases. This would mean that the server will collect the core dump during a kernel crash. Without the kdump service enabled, at times, we have the following scenario:
- The server crashes without any debug information;
- The customer wishes to investigate the problem further;
- Our team requests the core dump if the dmesg output wasn't informative enough;
- We stand by for another kernel crash before we would have all the information we need for debugging.
With the Kdump enabled, the process wouldn't get stuck on the "expecting a second server crash" phase if we need the core dump. Note that we still won't collect that information via KPR without your consent; you will need to contact our Support team for further help.
I don't want to share any kernel-related messages to you. Can I stop sending data to Kernel Panic Receiver?
Although we do not recommend this approach (as it will exclude your server from our proactive monitoring system, and we won't even know if something went wrong), you can disable sending data to KPR entirely. On a server-side, the KPR relies on the netconsole module; you just need to disable it. It runs as a service, so you need to stop it:
systemctl stop netconsole
systemctl disable netconsole
And comment out our remote IP address in the /etc/sysconfig/netconsole file.
# The IP address of the remote syslog server to send messages to
Worry not, it is safe to disable it with no harm done to other CloudLinux components. The netconsole module is used only to transmit kernel messages.