CentOs 7 не загружает аварийное ядро ​​и создает дамп в /var/crash

У нас есть проблема, из-за которой наш сервер CentOS 7 не создает файл дампа ядра в /var/crash при панике ядра. Похоже, аварийное ядро ​​никогда не загружается. Мы следовали руководству Rhel (http://red.ht/1sCztdv) по настройке аварийных дампов и на первый взгляд все настроено правильно. Мы вызываем панику следующим образом:

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

Это приводит к зависанию системы. Мы не получаем никаких сообщений на консоли, и консоль перестает отвечать на запросы. Я бы предположил, что в этот момент система загрузит аварийное ядро ​​и начнет записывать дамп в /var/crash. Я оставил его в этом замороженном состоянии на срок до 30 минут, чтобы дать ему время завершить весь дамп. Однако после жесткой холодной перезагрузки /var/crash пуст.

Кроме того, я воспроизвел конфигурацию на виртуальной машине KVM и слова kdump, как и ожидалось. Таким образом, либо что-то не так с моей конфигурацией в физической системе, либо что-то странное в этой конфигурации оборудования, что вызывает зависание, а не дамп.

Наш сервер — HP G9 с 24 ядрами и 128 ГБ памяти. Вот некоторые другие детали:

[user@host]$ cat /proc/cmdline

BOOT_IMAGE=/vmlinuz-3.10.0-123.el7.x86_64 root=UUID=287798f7-fe7a-4172-a35a-6a78051af4d2 ro rd.lvm.lv=vg_sda/lv_root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=vg_sda/lv_swap crashkernel=auto vconsole.keymap=us rhgb nosoftlockup intel_idle.max_cstate=0 mce=ignore_ce processor.max_cstate=0 idle=mwait isolcpus=2-11,14-23

[user@host]$ systemctl is-active kdump
active

[user@host]$ cat /etc/kdump.conf 

path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31 -c

[user@host]$ cat /proc/iomem |grep Crash
2b000000-357fffff : Crash kernel

[user@host]$ dmesg|grep Reserving
[    0.000000] Reserving 168MB of memory at 688MB for crashkernel (System RAM: 131037MB)

[user@host]$ df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/vg_sda-lv_root  133G  4.7G  128G   4% /
devtmpfs                     63G     0   63G   0% /dev
tmpfs                        63G     0   63G   0% /dev/shm
tmpfs                        63G  9.1M   63G   1% /run
tmpfs                        63G     0   63G   0% /sys/fs/cgroup
/dev/sda1                   492M  175M  318M  36% /boot
/dev/mapper/vg_sdb-lv_data  2.8T  145G  2.6T   6% /data

linux kernel coredump panic
person user3745855    schedule 15.01.2015    source источник
comment
Кроме того, я заметил, что консоль мерцает пустой, а затем возвращается к экрану входа в систему прямо перед тем, как перестает отвечать на запросы. Итак, похоже, что он пытается загрузить аварийное ядро, но по какой-то неизвестной причине терпит неудачу.   -  person user3745855    schedule 15.01.2015

Ответы (2)


arrow_upward
2
arrow_downward

После изменения следующих параметров мы смогли достоверно получить аварийные дампы:

  1. Crackkernel=auto изменен на crashkernel=1G: я не уверен, зачем нам нужен 1G, так как формула указывает 128M+64M на каждый 1 ТБ оперативной памяти.
  2. /etc/sysconfig/kdump: удалено все из KDUMP_COMMANDLINE_APPEND, кроме irqpoll nr_cpus=1, в результате получилось: KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1
  3. /etc/kdump.cfg: добавить сжатие («-c») в makedump

Не уверен на 100%, почему это работает, но работает. Хотелось бы узнать, что думают другие

Эрик

person user3745855    schedule 19.01.2015
comment
2) привел меня к тому, что сработало для меня: вместо этого я закомментировал всю строку KDUMP_COMMANDLINE_APPEND - person Danedo; 09.06.2019

arrow_upward
0
arrow_downward

Эрик,

1G кажется немного большим. Я никогда не видел ничего больше 200M для обычного сервера. Не уверен насчет настроек sysconfig. Сжатие — хорошая идея, но я не думаю, что это повлияет на проблему, поскольку ваша цель близка к общей памяти, и вы только сбрасываете кольцо ядра.

person Nick    schedule 01.02.2015
comment
Ника, полностью согласен. Однако, если ввести сумму менее 1 ГБ, я не получу аварийного дампа. Понятия не имею почему. - person user3745855; 02.02.2015