Это старая версия документа.
Содержание
Отчет о падении ядра
Введение
Отчет о падении ядра является частью содержимого оперативной памяти (RAM), которая копируется на диск всякий раз, когда выполнение ядра прерывается. Следующие события могут стать причиной остановки ядра:
Критическая ошибка ядра (Kernel Panic)
Незамаскированное прерывание (NMI)
Фатальная ошибка проверки машины (MCE)
Отказ оборудования
Ручное вмешательство
Некоторые из этих событий (паника, NMI) ядро обрабатывает автоматически и запускает механизм сохранения отчета через kexec. В других случаях требуется ручное вмешательство для захвата памяти. Всякий раз как что-то из перечисленного происходит, важно найти основную причину с целью предотвращения такого события снова. Причина может быть определена с помощью инспектирования содержимого памяти.
Механизм отчета о падении ядра
Когда происходит критическая ошибка ядра, ядро полагается на механизм kexec для быстрой перезагрузки новой копии ядра в предварительно зарезервированную секцию памяти, которая выделяется при загрузке системы. Это позволяет существующей памяти остаться нетронутой с целью безопасного копирования ее содержимого в файл.
Установка
Утилита сохранения отчета о падении ядра устанавливается следующей коммандой:
sudo apt-get install linux-crashdump
После этого потребуется перезагрузка.
Настройка
Никакой дальнейшей настройки не требуется чтобы разрешить механизм отчета о падении ядра.
Проверка
Для подтверждения, что механизм отчета о падении ядра доступен, надо проверить несколько вещей. Во-первых, убедитесь, что указан загрузочный параметр crashkernel. (заметьте, что строка внизу разделена на две для сохранения форматирования документа):
cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.2.0-17-server root=/dev/mapper/PreciseS-root ro crashkernel=384M-2G:64M,2G-:128M
Параметр crashkernel имеет следующий синтаксис:
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset] range=start-[end] 'start' is inclusive and 'end' is exclusive.
Таким образом с параметром crashkernel, найденным в файле /proc/cmdline мы имеем:
crashkernel=384M-2G:64M,2G-:128M
Значение выше означает:
если оперативная память меньше 384МБ, то ничего не резервировать (это вариант «спсения»)
если оперативная память между 384МБ и 2ГБ (привилегированная), то зарезервировать 64МБ
если оперативная память больше 2ГБ, то зарезервировать 128МБ
Во-вторых, убедитесь, что ядро зарезервировало требуемую память для kdump ядра, выполнив:
dmesg | grep -i crash ... [ 0.000000] Reserving 64MB of memory at 800MB for crashkernel (System RAM: 1023MB)
Testing the Crash Dump Mechanism
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 :
cat /proc/sys/kernel/sysrq
If a value of 0 is returned the feature is disabled. Enable it with the following command :
sudo sysctl -w kernel.sysrq=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 for ubuntu: # echo c > /proc/sysrq-trigger [ 31.659002] SysRq : Trigger a crash [ 31.659749] BUG: unable to handle kernel NULL pointer dereference at (null) [ 31.662668] IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20 [ 31.662668] PGD 3bfb9067 PUD 368a7067 PMD 0 [ 31.662668] Oops: 0002 [#1] SMP [ 31.662668] CPU 1 ….
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 kernel crash …
Once completed, the system will reboot to its normal operational mode. You will then find Kernel Crash Dump file in the /var/crash directory :
ls /var/crash linux-image-3.0.0-12-server.0.crash
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)