Pourquoi Linux kdump n'écrit-il pas dans / var / crash?

C'est encore arrivé! J'ai 4 serveurs qui se bloquent périodiquement, et aucune information n'est imprimée dans les journaux système ou la console série.

De plus, le service Linux kdump n'écrit pas les vidages mémoire à l'emplacement par défaut de /var/crash.

• Pouvez-vous m'aider à comprendre pourquoi?
• Est-il important que mon système de fichiers racine soit un volume LVM?

Voici ce que j'ai essayé.

1. Mon système est Scientific Linux 6.5 avec le dernier noyau.

   [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. Le fichier /etc/kdump.confest le fichier vanilla contenant les paramètres par défaut. La plupart des lignes sont commentées, il n'y a que deux lignes actives pour pathet core_collector.

   #net my.server.com:/export/tmp
   #net [email protected]
   path /var/crash
   core_collector makedumpfile -c --message-level 1 -d 31
   #core_collector scp
   

3. Je m'assure que le kdumpservice fonctionne, et cela kdumpn'a pas besoin de reconstruire mon 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. Ensuite, je force un crash du noyau à l'aide de ces commandes empruntées au RHEL6 Deployment Guide: Chapter 29. Le service kdump Crash Recovery :

   Tapez ensuite les commandes suivantes à l'invite du shell:

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

   Cela forcera le noyau Linux à planter

5. Le système se bloque. Je peux voir la progression sur ma console série. Je vois le message Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, mais immédiatement après cela, je vois l'étrange message de Usage: fsck.ext4, qui ressemble à quelque chose qui appelle accidentellement fsckau lieu de ce qu'il devrait faire. Je ne vois aucune mention d'une erreur de mémoire insuffisante ou quoi que ce soit.

   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. Et puis le système redémarre (ce qui est la valeur par défaut).

7. Lorsque le système revient en ligne, il n'y a plus rien /var/crash. Je suppose que le vidage sur incident n'a pas été écrit.

   [root@host1 ~]# ls -lA /var/crash/
   total 0
   [root@host1 ~]#
   

8. Je sais que les vidages sur incident peuvent fonctionner en général. Si je dis kdumpde copier le vidage de mémoire sur un autre système avec la configuration suivante, kdump réussira à écrire le vidage de mémoire sur un autre hôte:

   path vmcore
   ssh [email protected]
   sshkey /root/.ssh/kdump_id_rsa
   

9. Si je mets default shellen /etc/kdump.confet reconstruire initrd, puis planter le système à nouveau j'obtiens une erreur un peu plus d' information sur lesmount: 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. Mais maintenant, je suis coincé.

Un peu tard pour le jeu mais si vous avez besoin de configurer kdump pour le futur:

Je pense que la directive path désigne un chemin à partir de la partition ou du système de fichiers désigné. Par défaut, c'est le root fs. Si vous avez une partition séparée dans fstab pour / var, elle obscurcira le répertoire de plantage lorsque votre système démarrera normalement. c'est-à-dire si vous deviez démarrer normalement et démonter / var vous verriez le crash / [UniqCoreDir]. Vous pouvez ajuster cela en ajoutant une directive "ext4 / PATH / TO / DEVICE" dans kdump.conf. Vous pouvez également utiliser un chemin différent qui ne sera pas monté.

Juste une supposition mais peut-être un certain nombre de vmcores enterrés sous / var.

Séparez votre initrd kdump dans / boot / check pour voir le chemin final vers lequel il essaie de vider.

• Je pense que l'option "path" est un peu bizarre, je la laisserais probablement par défaut ou je la définirais explicitement sur / var / crash

• Avez-vous une sorte de chien de garde qui redémarre la machine? cela peut également empêcher la création du noyau en redémarrant la machine avant le démarrage de.