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


10

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 user@my.server.com
    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 user@hostb.example.org
    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é.


Quelle est la marque / le modèle du serveur?
ewwhite

Il s'agit d'un Supermicro avec une carte mère X9DRW4 et le dernier bios.
Stefan Lasiewski

Bummer. Je rencontre un crash similaire sur HP ProLiants avec le plus récent noyau RHEL6. Je me demande si c'est un problème plus profond.
ewwhite

Pour moi, cela ressemble un peu à un bug. Mais je ne me souviens pas à quoi devrait ressembler la sortie.
Stefan Lasiewski

1
Salut. As-tu résolu ce problème? Je suis confronté à un problème très similaire.
Chul-Woong Yang

Réponses:


5

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.


2

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.


Je vais vérifier l'initrd et voir ce que je trouve. L' pathoption dans # 2 est le chemin par défaut ( /var/crash).
Stefan Lasiewski

Non, je n'ai pas de chien de garde qui redémarre la machine. Il s'avère que le contrôleur LSI + les SSD Samsung se bloquent périodiquement pour des raisons que nous ne comprenons pas totalement.
Stefan Lasiewski

Avez-vous reçu des commentaires, car c'est assez fou, peut-être un problème de consommation électrique entraînant une baisse de tension trop faible?
Pas de nom d'utilisateur
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.