Почему Linux kdump не пишет в / var / crash?

10

Это случилось снова! У меня 4 сервера, которые периодически выходят из строя, и информация о них не распечатывается в журналах системы или последовательной консоли.

Кроме того, служба Linux kdump не записывает дампы ядра в расположение по умолчанию /var/crash.

  • Можете ли вы помочь мне понять, почему?
  • Имеет ли значение, если моя корневая файловая система является томом LVM?

Вот что я попробовал.

  1. Моя система - Scientific Linux 6.5 с последним ядром.

    [root@host1 ~]# uname -r
    2.6.32-431.11.2.el6.x86_64
    [root@host1 ~]# cat /etc/issue
    Scientific Linux release 6.5 (Carbon)
    
  2. Файл /etc/kdump.confявляется файлом vanilla, содержащим настройки по умолчанию. Большинство строк закомментированы, есть только две активные строки для pathи core_collector.

    #net my.server.com:/export/tmp
    #net user@my.server.com
    path /var/crash
    core_collector makedumpfile -c --message-level 1 -d 31
    #core_collector scp
    
  3. Я гарантирую, что kdumpслужба работает, и kdumpмне не нужно перестраивать мою initrd.

    [root@host1 ~]# chkconfig --list kdump
    kdump           0:off   1:off   2:off   3:on    4:on    5:on    6:off
    [root@host1 ~]# /etc/init.d/kdump restart
    Stopping kdump:                                            [  OK  ]
    Starting kdump:                                            [  OK  ]
    [root@host1 ~]# 
    
  4. Затем я принудительно вызываю сбой ядра с помощью этих команд, заимствованных из Руководства по развертыванию RHEL6: Глава 29. Служба восстановления после сбоя kdump :

    Затем введите следующие команды в командной строке:

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

    Это заставит ядро ​​Linux падать

  5. Система вылетает. Я могу видеть прогресс на моей последовательной консоли. Я вижу сообщение Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, но сразу после этого я вижу странное сообщение о том Usage: fsck.ext4, что нечто вроде случайного вызова fsckвместо того, что он должен делать. Я не вижу упоминания об ошибке нехватки памяти или о чем-либо еще.

    host1.example.org login: SysRq : Trigger a crash
    BUG: unable to handle kernel NULL pointer dereference at (null)
    ...
    ... skipping 50 lines of output
    ...
    Creating block device ram8
    Creating block device ram9
    Creating Remain Block Devices
    Making device-mapper control node
    Scanning logical volumes
      Reading all physical volumes.  This may take a while...
      No volume groups found
      No volume groups found
    Activating logical volumes
      No volume groups found
      No volume groups found
    Free memory/Total memory (free %): 58272 / 116616 ( 49.9691 )
    Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2
    Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
            [-I inode_buffer_blocks] [-P process_inode_size]
            [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
            [-E extended-options] device
    
    Emergency help:
     -p                   Autom
    
  6. Затем система перезагружается (по умолчанию).

  7. Когда система возвращается в оперативный режим, ничего не происходит /var/crash. Я предполагаю, что аварийный дамп не был записан.

    [root@host1 ~]# ls -lA /var/crash/
    total 0
    [root@host1 ~]#
    
  8. Я знаю, что аварийные свалки могут работать вообще. Если я скажу kdumpскопировать дамп ядра в другую систему со следующей конфигурацией, kdump успешно запишет дамп ядра на другой хост:

    path vmcore
    ssh user@hostb.example.org
    sshkey /root/.ssh/kdump_id_rsa
    
  9. Если установить default shellв /etc/kdump.confи восстановить Initrd, а затем обрушить систему снова я получаю немного более информативное сообщение об ошибке оmount: can't find /mnt in /etc/fstab

    Free memory/Total memory (free %): 58272 / 116616 ( 49.9691 )
    Saving to the local filesystem UUID=e720481b-1987-4c69-a867-f2b4cba3b312
    Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
    [-I inode_buffer_blocks] [-P process_inode_size]
    [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
    [-E extended-options] device
    
    Emergency help:
     -p                   Automatic repair (no questions)
     -n                   Make no changes to the filesystem
     -y                   Assume "yes" to all questions
     -c                   Check for bad blocks and add them to the badblock list
     -f                   Force checking even if filesystem is marked clean
     -v                   Be verbose
     -b superblock        Use alternative superblock
     -B blocksize         Force blocksize when looking for superblock
     -j external_journal  Set location of the external journal
     -l bad_blocks_file   Add to badblocks list
     -L bad_blocks_file   Set badblocks list
    mount: can't find /mnt in /etc/fstab
    dropping to initramfs shell
    exiting this shell will reboot your system
    /sys/block #
    
  10. Но сейчас я застрял.

Стефан Ласевский
источник
Что такое марка / модель сервера?
Ewwhite
Это Supermicro с материнской платой X9DRW4 и новейшим BIOS.
Стефан Ласевски
Облом. У меня похожий сбой на HP ProLiants с новейшим ядром RHEL6. Мне интересно, если это более глубокая проблема.
Ewwhite
Для меня это выглядит как ошибка. Но я не помню, как должен выглядеть результат.
Стефан Ласевский
1
Привет. Вы решили эту проблему? Я сталкиваюсь с очень похожей проблемой.
Чул-Вунг Ян,

Ответы:

5

Немного опоздал к игре, но если вам нужно настроить kdump на будущее:

Я думаю, что директива path обозначает путь от обозначенного раздела или файловой системы. По умолчанию это корень фс. Если у вас есть отдельный раздел в fstab для / var, он запутывает каталог сбоев, когда ваша система загружается нормально. т. е. если бы вы загружались нормально и размонтировали / var, вы бы увидели сбой / [UniqCoreDir]. Вы можете изменить это, добавив директиву ext4 / PATH / TO / DEVICE в kdump.conf. Также вы можете использовать другой путь, который не будет смонтирован поверх.

Просто предположение, но может быть несколько vmcores, похороненных в / var.

Ник
источник
2

Разберите ваш kdump initrd в / boot / check, чтобы увидеть окончательный путь, к которому он пытается создать дамп.

  • Я думаю, что опция "путь" немного странная, я бы, вероятно, оставил ее по умолчанию или явно установил / var / crash

  • У вас есть какой-то сторожевой таймер, перезагружающий машину? это также может предотвратить создание ядра путем перезагрузки компьютера перед его запуском.

Нет имени пользователя
источник
Я проверю initrd и посмотрю, что я найду. Параметр pathв # 2 является путем по умолчанию ( /var/crash).
Стефан Ласевский,
Нет, у меня нет сторожевого таймера, перезагружающего машину. Оказывается, что контроллер LSI + твердотельные накопители Samsung периодически зависают по причинам, которые мы до конца не понимаем.
Стефан Ласевский
Получили ли вы какие-либо отзывы, потому что это довольно безумно, может быть, проблема с потреблением энергии при слишком низком напряжении?
Без имени пользователя