Es ist wieder passiert! Ich habe 4 Server, die regelmäßig abstürzen, und es werden keine Informationen in die Systemprotokolle oder die serielle Konsole gedruckt.
Darüber hinaus schreibt der Linux- kdump-Dienst keine Core-Dumps an den Standardspeicherort von /var/crash.
- Können Sie mir helfen, herauszufinden, warum?
- Ist es wichtig, ob mein Root-Dateisystem ein LVM-Volume ist?
Folgendes habe ich versucht.
Mein System ist Scientific Linux 6.5 mit dem neuesten Kernel.
[root@host1 ~]# uname -r 2.6.32-431.11.2.el6.x86_64 [root@host1 ~]# cat /etc/issue Scientific Linux release 6.5 (Carbon)Die Datei
/etc/kdump.confist die Vanille-Datei mit den Standardeinstellungen. Die meisten Zeilen sind auskommentiert, es gibt nur zwei aktive Zeilen fürpathundcore_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 scpIch stelle sicher, dass der
kdumpDienst ausgeführt wird und dasskdumpmein Dienst nicht neu erstellt werden mussinitrd.[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 ~]#Dann erzwinge ich einen Kernel-Absturz mit diesen Befehlen, die aus dem RHEL6-Bereitstellungshandbuch entlehnt wurden : Kapitel 29. Der kdump-Absturzwiederherstellungsdienst :
Geben Sie dann an einer Shell-Eingabeaufforderung die folgenden Befehle ein:
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-triggerDadurch wird der Linux-Kernel zum Absturz gebracht
Das System stürzt ab. Ich kann den Fortschritt auf meiner seriellen Konsole anzeigen. Ich sehe die Nachricht
Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, aber unmittelbar danach sehe ich die seltsame NachrichtUsage: fsck.ext4, welche Art von Aussehen versehentlich anruft,fsckanstatt was auch immer es tun soll. Ich sehe keine Erwähnung eines Speichermangels oder irgendetwas.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 AutomAnschließend wird das System neu gestartet (dies ist die Standardeinstellung).
Wenn das System wieder online ist, ist nichts drin
/var/crash. Ich gehe davon aus, dass der Crash Dump nicht geschrieben wurde.[root@host1 ~]# ls -lA /var/crash/ total 0 [root@host1 ~]#Ich weiß, dass Crash-Dumps im Allgemeinen funktionieren können. Wenn ich
kdumpden Core-Dump mit der folgenden Konfiguration auf ein anderes System kopieren soll, schreibt kdump den Core-Dump erfolgreich auf einen anderen Host:path vmcore ssh user@hostb.example.org sshkey /root/.ssh/kdump_id_rsaWenn ich gesetzt
default shellin/etc/kdump.confund Wiederaufbau initrd, und dann das System zum Absturz wieder erhalte ich einen etwas informativer Fehler zumount: can't find /mnt in /etc/fstabFree 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 #Aber jetzt stecke ich fest.