再び起こった！定期的にクラッシュするサーバーが4台あり、システムログやシリアルコンソールに情報が出力されません。
さらに、Linux kdumpサービスはコアダンプをデフォルトの場所に書き込みません/var/crash。
- 理由を教えてください。
- ルートファイルシステムがLVMボリュームであるかどうかは重要ですか？
これが私が試したものです。
私のシステムは、最新のカーネルを備えたScientific Linux 6.5です。
[root@host1 ~]# uname -r 2.6.32-431.11.2.el6.x86_64 [root@host1 ~]# cat /etc/issue Scientific Linux release 6.5 (Carbon)このファイル
/etc/kdump.confは、デフォルト設定を含む標準的なファイルです。ほとんどの行はコメント化されており、pathおよびのアクティブな行は2つだけ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 scpkdumpサービスが実行中であることを確認します。これkdumpにより、を再構築する必要はありません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 ~]#次に、RHEL6導入ガイドから借用した次のコマンドを使用して、カーネルクラッシュを強制します。第29章。kdumpクラッシュリカバリサービス：
次に、シェルプロンプトで次のコマンドを入力します。
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-triggerこれにより、Linuxカーネルが強制的にクラッシュします。
システムがクラッシュします。進行状況をシリアルコンソールで確認できます。私は、メッセージが表示され
Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2ますが、その直後、私は奇妙なメッセージが表示さUsage: fsck.ext4何かが誤って呼び出しているように見えるの一種、fsck代わりにそれはやるべきものは何でも。メモリ不足エラーなどについては何も触れられていません。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その後、システムが再起動します（これがデフォルトです）。
システムがオンラインに戻ると、には何も表示されません
/var/crash。クラッシュダンプが書き込まれていないと思います。[root@host1 ~]# ls -lA /var/crash/ total 0 [root@host1 ~]#クラッシュダンプは一般的に機能することがわかっています。
kdump次の構成でコアダンプを別のシステムにコピーするように指示すると、kdumpは別のホストにコアダンプを正常に書き込みます。path vmcore ssh user@hostb.example.org sshkey /root/.ssh/kdump_id_rsainitrd を設定
default shellし/etc/kdump.confて再構築し、その後システムをクラッシュさせた場合、次のような情報が表示されますmount: 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 #しかし、今、私は行き詰まっています。