kdump перестал работать к событию катастрофического отказа лог-сервера
Я выполняю Сервер Ubuntu 14.04 на машине, которая испытывает случайные катастрофические отказы при загрузке. Сервер не перезапускает независимо, но это становится недоступным через ssh или прямое соединение KVM.
Я подозреваю проблемы ЦП, но я ищу дымящееся оружие, таким образом, я следую инструкциям здесь:
https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
Однако никакой файл журнала не появляется в /var/crash или после естественного или после вызванного катастрофического отказа.
Подробнее:
(Я вызвал катастрофический отказ между каждым изменением, описанным здесь без изменения.)
Все пошло гладко, пока я не добрался до этого шага:
$ cat /sys/kernel/kexec_crash_loaded
0
Ожидаемый вывод равнялся 1. Немного рытья привело меня к /etc/default/kdump-tools, где я установил USE_KDUMP=1. Когда это не работало, добавил я KDUMP_SYSCTL="kernel.panic=60 kernel.panic_on_oops=1" на основе sysctl документации. Все еще никакая радость, таким образом, я изменил параметрический усилитель непосредственно с sysctl -w kernel.panic=60 предположительно, добавить дополнительное время для kdump, чтобы сделать его вещь.
В каждом случае я работал бы:
echo c | sudo tee /proc/sysrq-trigger
Компьютер отказал бы и перезагрузка как ожидалось, но все, что я буду видеть, является этим:
$ ls /var/crash
kexec_cmd
/var/log/kern.log содержит только записи в журнале от начальной загрузки, не от катастрофических отказов. (Не уверенный, если бы это ожидается, но я думал, что упомянул бы это так или иначе.)
Есть ли что-то не так с моей конфигурацией?
2 ответа
Если /boot находится на отдельном разделе, Дамп Катастрофического отказа Ядра на Ubuntu перестанет работать из-за---> ошибка, которая все еще существует в 14.04 Надежных людях, можно ли верить этому? По крайней мере, это имеет место для меня использующий LVM и отдельное /boot.
Обходное решение к
unmount /bootи затем смонтируйте его к некоторой другой точке монтирования, например./mnt- скопируйте содержание в
/boot(тот на том же блочном устройстве как/). например.rsync -axHAX --progress --stats /mnt/ /boot - Инициируйте катастрофический отказ при помощи
echo c | sudo tee /proc/sysrq-trigger - Если вся польза, Вы будете видеть, что ядро разрушает дамп в
/var/crashв формах (uname-r)-yyyymmddHHmm.crash и yyyymmddHHmm каталог с dmesg и дампом.
Если Вы захотите проанализировать дамп катастрофического отказа, то Вам будет нужно crash, выполните его как ниже:
crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/yyyymmddHHmm/dump.yyyymmddHHmm
Для большего количества информации относительно катастрофического отказа прочитайте руководство.
BTW: НЕ забывайте перезагружать конфигурацию kdump-инструментов после изменения /etc/default/kdump-tools kdump-config load.
Возможно, это - зарезервированная память, является слишком маленьким. (моя проблема, вызванная этой причиной).
Я думаю, что необходимо проверить правильную вещь от трех шагов. Во-первых, проверьте, что Ваша конфигурация, следуют [дамп Катастрофического отказа ядра Ubuntu] :https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html
Во-вторых, dmesg|grep -i crash, проверять зарезервированную память в порядке.
В-третьих, service kdump-tools status проверять загрузку kdump ядро в порядке.
На третьем шаге журнал очень важен, Ваш может видеть /var/log/syslog найти журналы. и затем определите причину.