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é.
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)
Le fichier
/etc/kdump.conf
est 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 pourpath
etcore_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'assure que le
kdump
service fonctionne, et celakdump
n'a pas besoin de reconstruire moninitrd
.[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 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
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 deUsage: fsck.ext4
, qui ressemble à quelque chose qui appelle accidentellementfsck
au 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
Et puis le système redémarre (ce qui est la valeur par défaut).
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 ~]#
Je sais que les vidages sur incident peuvent fonctionner en général. Si je dis
kdump
de 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
Si je mets
default shell
en/etc/kdump.conf
et 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 #
Mais maintenant, je suis coincé.