Ubuntu Server Guide Changes, errors and bugs

Testing the Crash Dump Mechanism
Warning
Testing the Crash Dump Mechanism will cause a system reboot. In certain situations, this can
cause data loss if the system is under heavy load. If you want to test the mechanism, make sure
that the system is idle or under very light load.
Verify that the SysRQ mechanism is enabled by looking at the value of the /proc/sys/kernel/sysrq kernel
parameter :
c a t / p r o c / s y s / k e r n e l / s y s r q
If a value of 0 is returned the dump and then reboot feature is disabled. A value greater than 1 indicates that
a sub-set of sysrq features is enabled. See /etc/ sysctl .d/10−magic−sysrq.conf for a detailed description of
the options and the default value. Enable dump then reboot testing with the following command :
sudo s y s c t l −w k e r n e l . s y s r q =1
Once this is done, you must become root, as just using sudo will not be sufficient. As the root user, you will
have to issue the command echo c > /proc/sysrq−trigger. If you are using a network connection, you will
lose contact with the system. This is why it is better to do the test while being connected to the system
console. This has the advantage of making the kernel dump process visible.
A typical test output should look like the following :
sudo −s
[ sudo ] password f o r ubuntu :
# echo c > / p r o c / s y s r q −t r i g g e r
[
3 1 . 6 5 9 0 0 2 ] SysRq : T r i g g e r a c r a s h
[
3 1 . 6 5 9 7 4 9 ] BUG: u n a b l e t o h a n d l e k e r n e l NULL p o i n t e r d e r e f e r e n c e a t
( n u l l )
[
3 1 . 6 6 2 6 6 8 ] IP : [< f f f f f f f f 8 1 3 9 f 1 6 6 >] sys rq_handl e_c rash+0x16 /0 x20
[
3 1 . 6 6 2 6 6 8 ] PGD 3 bfb9067 PUD 368 a7067 PMD 0
[
3 1 . 6 6 2 6 6 8 ] Oops : 0002 [ # 1 ] SMP
[
3 1 . 6 6 2 6 6 8 ] CPU 1
. . . .
21

---

The rest of the output is truncated, but you should see the system rebooting and somewhere in the log, you
will see the following line :
Begin : Saving vmcore from k e r n e l c r a s h . . .
Once completed, the system will reboot to its normal operational mode. You will then find the Kernel Crash
Dump file, and related subdirectories, in the /var/crash directory :
l s / var / c r a s h
201809240744
kexec_cmd
l i n u x −image −4.15.0 −34 − g e n e r i c −201809240744. c r a s h
If the dump does not work due to OOM (Out Of Memory) error, then try increasing the amount of reserved
memory by editing /etc/default/grub.d/kdump−tools.cfg. For example, to reserve 512 megabytes :
GRUB_CMDLINE_LINUX_DEFAULT=”$GRUB_CMDLINE_LINUX_DEFAULT c r a s h k e r n e l =384M−:512M
”
run sudo update−grub and then reboot afterwards, and then test again.
Resources
Kernel Crash Dump is a vast topic that requires good knowledge of the linux kernel. You can find more
information on the topic here :
• Kdump kernel documentation.
• The crash tool
• Analyzing Linux Kernel Crash (Based on Fedora, it still gives a good walkthrough of kernel dump
analysis)