Чому Linux kdump не пише в / var / crash?

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

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

• Чи можете ви допомогти мені зрозуміти, чому?
• Чи має значення, якщо моя коренева файлова система має об'єм LVM?

Ось що я спробував.

1. Моя система - Науковий 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- це ванільний файл, що містить налаштування за замовчуванням. Більшість рядків коментовано, є лише дві активні лінії для 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. Але зараз я застряг.

Трохи пізно в грі, але якщо вам потрібно налаштувати kdump на майбутнє:

Я думаю, що директива шляху позначає шлях від призначеного розділу чи файлової системи. За замовчуванням це корінь fs. Якщо у вас є окремий розділ у fstab for / var, він заблокує каталог збоїв при нормальній завантаженні системи. тобто, якщо ви завантажувались нормально та відключали / var, ви побачили б збій / [UniqCoreDir]. Ви можете скоригувати це, додавши директиву "ext4 / PATH / TO / DEVICE" у kdump.conf. Також ви можете використовувати інший шлях, який не буде змонтований.

Лише здогадка, але, можливо, буде введено ряд vmcores під / var.

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

• Я думаю, що варіант "шлях" трохи дивний, я, мабуть, залиште його за замовчуванням або встановіть його явно в / var / crash

• У вас є якась сторожова собака, яка перезавантажує машину? це також може запобігти створенню ядра шляхом перезавантаження машини перед запуском.