Pourquoi Linux Kdump n'écrit-il pas à / var / crash?

Question

C'est arrivé à nouveau! J'ai 4 serveurs qui tombent périodiquement et il n'y a aucune information imprimée sur les journaux système ou la console de série.

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

Pouvez-vous m'aider à comprendre pourquoi?
Est-ce qu'il importe si mon système de fichiers racine est un volume LVM?

Voici ce que j'ai essayé.

Mon système est scientifique 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)

Le fichier /etc/kdump.conf est le fichier vanille contenant les paramètres par défaut. La plupart des lignes sont commentées, il n'y a que deux lignes actives pour path et 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 
```

Je m'assurens que le service kdump est en cours d'exécution et que kdump n'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 ~]#

Ensuite, je forcise un crash de noyau en utilisant ces commandes empruntées à partir du Guide de déploiement RHEL6: Chapitre 29. Le service de récupération de Crash Kdump :
Tapez ensuite les commandes suivantes à une invite de Shell:
```
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger 
```
Cela obligera le noyau Linux à se bloquer

Le système se bloque. Je peux voir les progrès sur ma console de série. Je vois le message Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, mais immédiatement après que je vois le message étrange de Usage: fsck.ext4, qui ressemble à quelque chose, appelait accidentellement fsck au lieu de ce qu'il devrait faire. Je ne vois aucune mention d'une erreur hors de mémoire ou de 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

Puis le système redémarre (qui est la valeur par défaut).
Lorsque le système revient en ligne, il n'y a rien dans /var/crash. Je suppose que le déchargement n'a pas été écrit.
```
[root@Host1 ~]# ls -lA /var/crash/ total 0 [root@Host1 ~]# 
```
Je sais que les décharges de crash peuvent travailler en général. Si je dis kdump _ Pour copier le vidage du noyau à un autre système avec la configuration suivante, Kdump écrira avec succès le dépotoir de base à un autre hôte:
```
path vmcore ssh user@hostb.example.org sshkey /root/.ssh/kdump_id_rsa 
```

Si je mets default Shell dans /etc/kdump.conf et reconstruit initrd, puis planter le système à nouveau, je reçois une erreur légèrement plus informative sur 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 #

Mais maintenant, je suis coincé.

nick · Answer

Un peu tard au jeu, mais si vous devez configurer KDump pour l'avenir:

Je pense que la directive sur le chemin désigne un chemin de la partition ou du système de fichiers désigné. Par défaut, c'est la racine FS. Si vous avez une partition séparée dans FSTAB pour/var, il obfusez le répertoire de crash lorsque votre système est démarré normalement. C'est-à-dire que si vous deviez démarrer normalement et que vous trouviez/var, vous verriez le crash/[uniqcoredrir]. Vous pouvez ajuster cela en ajoutant une directive "ext4/chemin/périphérique" dans kdump.conf. Vous pouvez également utiliser un chemin différent qui ne sera pas monté sur.

Juste une hypothèse mais pourrait avoir un certain nombre de vmcores courtises sous/var.

No Username · Answer

Tirez séparément votre Kdump Initier in/Boot/Vérifiez pour voir le chemin final que celui qui tente de vider.

Je pense que l'option "chemin" est un peu bizarre, je laisserais probablement la valeur par défaut ou la définir explicitement sur/var/crash
Avez-vous une sorte de chien de garde redémarifiant la machine? Cela peut également empêcher le noyau d'être créé en redémarrant la machine avant le démarrage de la machine.