9

I was playing a game on Steam and all a sudden I got a kernel panic. I manually shut down the computer and booted back into Linux Mint 17.1 (Cinnamon) 64-bit, and went to go check through my log files in /var/log/, but I couldn't find any references or any kind of messages relating to the kernel panic that happened.

It's strange why it never dumped the core or even made any note of it into the log files. How can I make sure that a core is always dumped in case a kernel panic happens again? Doesn't make any sense why nothing was logged when a kernel panic happened. Looking around on Google, people suggest to read through /var/log/dmesg, /var/log/syslog, /var/log/kern.log, /var/log/Xorg.log etc… but nothing. Not even in .Xsession-errors file either.

Here are some photographs of the screen:
Kernel Panic (image2) Kernel Panic (image1)

I could always take a photo of the screen when and if it happens again, but I just want to make sure that I can get it to dump the core and create a log file on a kernel panic.

G-Man Says 'Reinstate Monica'
  • 22,130
  • 27
  • 68
  • 117

2 Answers2

8

To be sure that your machine generates a "core" file when a kernel failure occurs, you should confirm the "sysctl" settings of your machine.

IMO, following should be the settings (minimal) in /etc/sysctl.conf:

kernel.core_pattern = /var/crash/core.%t.%p
kernel.panic=10
kernel.unknown_nmi_panic=1

Execute sysctl -p after making changes in the /etc/sysctl.conf file.  You should probably also mkdir /var/crash if it doesn’t already exist.

You can test the above by generating a manual dump using the SysRq key (the key combination to dump core is Alt+SysRq+C).

G-Man Says 'Reinstate Monica'
  • 22,130
  • 27
  • 68
  • 117
shubham
  • 407
  • 3
  • 12
  • This seems to be a start at something. I had to write these as new entry into sysctl since it wasn't there in the file. I did the `Alt+SysRq+C` with the keys but it didn't do anything, it just flashed the screen. I'm also using Laptop so the keys might be different. I did try `fn+SysRq+C` but that did the same as before. –  Apr 07 '15 at 13:18
  • Please share the output of "cat /proc/sys/kernel/sysrq". It might be possible that sysrq is disable on your machine. Refer: https://www.kernel.org/doc/Documentation/sysrq.txt for more details – shubham Apr 08 '15 at 04:07
  • the output of that gives me 176 –  Apr 09 '15 at 12:54
  • Edit the file /etc/sysctl.conf to include the line --> kernel.sysrq=1 – shubham Apr 10 '15 at 03:52
  • 1
    @user94959 Does it works for you ? – shubham Jan 11 '16 at 06:22
  • I believe so it worked. –  Jan 12 '16 at 07:17
3

When the kernel panics, it means something has gone wrong in the kernel. Writing log files and core dumps requires using the drivers for the block storage device (your disk) and the filesystem (space has to be allocated, and the size of the log file has to be updated). Given those services that are provided by the kernel are required in order to write files, and the kernel knows it is in a broken state, it cannot write the files or log anything, because it isn't in a safe state anymore, so doing any operation could make things worse and could damage/destroy your filesystem. So you cannot have the kernel write to the log nor dump a core dump when it panics.

Now what you can do, if you want to, is configure the system with a crash handling kernel, which is a second kernel loaded into memory that control can be transferred to if the main kernel crashes. Since that kernel has drivers and such, it would be able to save a crash dump for you. This is not a very common setup, though, and mainly used for high-end systems that require high availability and where a crash is a very serious issue that must be investigated.

See for example the crashkernel option at Kernel Crash Dump at ubuntu.com.  (Note that this page says that the kernel crash dump mechanism is enabled by default, starting with Ubuntu 16.04.)

I believe that system actually saves the dump to a reserved piece of memory and then reboots, and the kernel saves the reserved memory to disk on next boot (since the newly booting kernel is in a sane state and can do that).

G-Man Says 'Reinstate Monica'
  • 22,130
  • 27
  • 68
  • 117
Len Sorensen
  • 31
  • 1
  • The page at ubuntu.com describes the mechanism slightly differently: it says that the kernel reboots itself into a reserved area of memory, so the memory that it had been using before the disruption (i.e., the memory that you want to dump) will remain intact.  And I believe that it’s not as exotic as you make it sound (as it is now enabled by default). – G-Man Says 'Reinstate Monica' May 26 '17 at 19:47