web-dev-qa-db-ja.com

Linux kdumpが/ var / crashに書き込まないのはなぜですか？

再び起こった！定期的にクラッシュする4台のサーバーがあり、システムログやシリアルコンソールに情報が出力されません。

さらに、Linux kdump service はコアダンプをデフォルトの場所/var/crashに書き込みません。

  • 理由を教えてください。
  • ルートファイルシステムがLVMボリュームであるかどうかは重要ですか？

これが私が試したものです。

  1. 私のシステムは最新のカーネルを備えた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)

  2. ファイル/etc/kdump.confは、デフォルト設定を含むVanillaファイルです。ほとんどの行はコメント化されており、pathとcore_collectorのアクティブな行は2つだけです。

    #net my.server.com:/export/tmp
#Net [email protected]
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31
#core_collector scp

  3. kdumpサービスが実行されていること、および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 ~]#

  4. 次に、 RHEL6 Deployment Guide：Chapter 29. kdump Crash Recovery Service から借用したこれらのコマンドを使用して、カーネルクラッシュを強制します。

    次に、シェルプロンプトで次のコマンドを入力します。

    echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

    これにより、Linuxカーネルが強制的にクラッシュします。

  5. システムがクラッシュします。進行状況をシリアルコンソールで確認できます。メッセージ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

  6. その後、システムが再起動します（これがデフォルトです）。

  7. システムがオンラインに戻ったとき、/var/crashには何もありません。クラッシュダンプが書き込まれていないと思います。

    [root@Host1 ~]# ls -lA /var/crash/
total 0
[root@Host1 ~]#

  8. クラッシュダンプは一般的に機能することがわかっています。コアダンプを次の構成で別のシステムにコピーするようにkdumpに指示すると、kdumpはコアダンプを別のホストに正常に書き込みます。

    path vmcore
ssh [email protected]
sshkey /root/.ssh/kdump_id_rsa

  9. default Shellに/etc/kdump.confを設定してinitrdを再構築し、システムを再度クラッシュさせると、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 #

  10. しかし、今、私は行き詰まっています。

linuxrhel6server-crashesscientific-linuxkdump
10
Stefan Lasiewski

ゲームには少し遅れますが、将来のためにkdumpを構成する必要がある場合：

パスディレクティブは、指定されたパーティションまたはファイルシステムからのパスを指定していると思います。デフォルトでは、これはルートfsです。/varのfstabに別のパーティションがある場合、システムが正常に起動するとクラッシュディレクトリが難読化されます。つまり、正常に起動して/ varをアンマウントすると、crash/[UniqCoreDir]が表示されます。これを調整するには、kdump.confに「ext4/PATH/TO/DEVICE」ディレクティブを追加します。また、マウントされない別のパスを使用することもできます。

単なる推測ですが、/ varの下に多数のvmcoreが埋め込まれている可能性があります。

5
nick

/ boot /でkdump initrdを分解して、ダンプ先の最終的なパスを確認します。

  • 「パス」オプションは少し変だと思います。おそらくデフォルトのままにするか、明示的に/ var/crashに設定します

  • マシンを再起動する何らかのウォッチドッグがありますか？これにより、が起動する前にマシンを再起動してコアが作成されない場合もあります。

2
No Username