概要
CentOS6.9にてカーネルパニックした時のカーネルダンプ出力の設定メモ
カーネルパニックとは
- カーネルで致命的なエラーが発生し、OSの稼動が完全に停止した状態の事。カーネルが自発的にpanic()関数を実行した際に発生する。
- カーネルの設定でパニックした時に再起動する設定をいれていないと、停止したままになる。
./kernel/panic.cで定義しているみたい。
(v3.3.4)$ grep -r "void panic(" ./
./include/linux/kernel.h:void panic(const char *fmt, ...)
./kernel/panic.c:void panic(const char *fmt, ...)
./arch/unicore32/include/asm/system.h:extern void panic(const char *fmt, ...);
./arch/um/include/shared/user.h:extern void panic(const char *fmt, ...)
流れ
カーネルパニック発生
↓
クラッシュカーネルに処理を移行
↓
クラッシュカーネルでカーネルダンプを出力する
クラッシュカーネルが起動するのは安全のため。クラッシュカーネルが起動するための領域をブートローダの設定ファイルで予約しないといけない。
予約すると、下記の様にカーネルがクラッシュカーネルを配置する領域を獲得する。
# cat /proc/iomem
00000000-00000fff : reserved
00001000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c8bff : Video ROM
000c9000-000c97ff : Adapter ROM
000c9800-000cb9ff : Adapter ROM
000f0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-dfffcfff : System RAM
01000000-01556f04 : Kernel code
01556f05-01c2170f : Kernel data
01d77000-02045963 : Kernel bss
03000000-0b0fffff : Crash kernel
設定
必要なパッケージ
yum install kexec-tools
kdump コマンドが使えるようになる。
必要な設定
/etc/gurb/grub.cfg (grub1の場合)
- ブートローダのkernel行にcrashkernel=値を設定
- メインメモリが4GB以上のときはcrashkernel=autoで自動でクラッシュカーネルの領域を設定してくれる。それ以下の場合、デフォルトでは128MBに物理メモリー1TBごとに64 MB を加えたものを設定する。なので4GB以下の場合はcrashkernel=128Mで良さそう。Bはいらない。
- RHEL6の場合は値はcrashkernel=値、RHEL5の場合はcrashkernel=値@値になる
kdumpコマンド
service kdump start
あとはchkconfigでOS起動時にサービスが起動するようにする
デフォルトはcrashkernel=auto
になっていて、もしメモリが4GBより少ない場合、下記のようなエラーになるので、crashkernel=128M
に設定して再起動するとうまくいく。
# service kdump restart
Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
Stopping kdump: [FAILED]
Starting kdump: [FAILED]
再起動設定
何も設定していないとカーネルパニックを起こしたらそのまま停止状態になる。それだとめんどくさいので、再起動するように設定をする。下記は10秒後に再起動する。
kernel.panic = 10
sysctl -p
で有効にする。
カーネルダンプの出力先
- 設定ファイル
- /etc/kdump.conf
・
・
#raw /dev/sda5
#ext4 /dev/sda3
#ext4 LABEL=/boot
#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
#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
#core_collector cp --sparse=always
#extra_bins /bin/cp
#link_delay 60
#kdump_post /var/crash/scripts/kdump-post.sh
#extra_bins /usr/bin/lftp
#disk_timeout 30
#extra_modules gfs2
#options modulename options
#default shell
#debug_mem_level 0
#force_rebuild 1
#sshkey /root/.ssh/kdump_id_rsa
#fence_kdump_args -p 7410 -f auto -c 0 -i 10
#fence_kdump_nodes node1 node2
- デフォルトだと/var/crash/タイムスタンプ/vmcore。設定でリモートや普段アンマウントしているファイルシステムも設定できる。
- 通常の運用だと別ディスクとか専用のパーティションを区切ったりするのがよいみたい
出力サイズ
メモリ使用量によって変動しそう。
メモリ4.5Gくらい使用している場合。あまり大きなサイズにはならないのかな??
$ ls -lh
total 105M
-rw-------. 1 root root 105M May 12 07:12 vmcore
-rw-r--r--. 1 root root 30K May 12 07:11 vmcore-dmesg.txt
テスト
意図的にカーネルパニックを発動できる
echo c > /proc/sysrq-trigger
上手くいけば/var/crash/以下にカーネルダンプが出力される。
メモ
カーネルダンプの設定などにかかわらず、カーネルパニックが起きたら/var/log/messages
などにログが残るのかと思っていたら、panicに関するログは出力されなかった。
↑で言及されているように、カーネルパニックがおきてもそのメッセージは実際の画面で確認するしかなさそう。ただ、netconsoleなどでそのメッセージをリモートに送ることができるみたい。
参考
http://itpro.nikkeibp.co.jp/article/Keyword/20100917/352164/
http://blogs.itmedia.co.jp/komata/2016/07/linux_1.html
http://www.intellilink.co.jp/article/column/oss01.html