前回の続き 。abrtd で カーネルパニック時の vmcore を採取する
まとめ
検証作業をしてみた結果、正確には、
- kdump が起動していて、
- カーネルパニック後に kdump で vmcore を採取できた場合、
- 再起動後に vmcore + 予備情報を /var/crash 以下にまとめてくれる
と理解した。abrtd が全部よしなにやってくれると思ってしまったが、vmcore を採取するのは kdump の仕事だった。
kdump の設定
kdump.service の準備が必要。 Red Hat のドキュメントを読もう
Red Hat Enterprise Linux - カーネルクラッシュダンプガイド - 2.2. コマンドラインで KDUMP を設定する
tips: Vagrant + CentOS7 で試す場合
crashkernel=auto でハマないように!
設定変更
検証作業なので grub2 設定をシェルで書き換えていく
$ sudo systemctl enable kdump.service $ sudo perl -i'.bak' -nlpe 's/crashkernel=auto/crashkernel=128M/' /etc/default/grub $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg $ sync $ sudo reboot
reboot 後に kdump の status を確認しよう
$ sudo systemctl status kdump ● kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled) Active: active (exited) since 日 2016-12-25 07:32:46 EST; 14h ago Process: 1758 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS) Main PID: 1758 (code=exited, status=0/SUCCESS) CGroup: /system.slice/kdump.service 12月 25 07:32:30 localhost.localdomain systemd[1]: Starting Crash recovery kernel arming... 12月 25 07:32:46 localhost.localdomain kdumpctl[1758]: kexec: loaded kdump kernel 12月 25 07:32:46 localhost.localdomain kdumpctl[1758]: Starting kdump: [OK] 12月 25 07:32:46 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.
カーネルパニックを起こす
kdump の用意ができたら echo c > /proc/sysrq-trigger で 秘孔を突いて カーネルパニックを起こす
$ echo c | sudo tee /proc/sysrq-trigger
VM が再起動した後に、ログインして abrt-cli でレポートを一覧する
不備が無ければ BUG: unable to handle kernel NULL pointer dereference at (null) がキャッチされているはず
$ sudo abrt-cli ls id 5f8ee8234bfdd61810b08d481291fa5d07ef4a6d reason: BUG: unable to handle kernel NULL pointer dereference at (null) time: Sun Dec 25 21:50:39 2016 uid: 0 (root) count: 1 Directory: /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42 Reported: cannot be reported
/var/spool/abrt 以下には下記のようなデータが採取されている
$ sudo ls -hal /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42 total 33M drwx------. 2 root root 4.0K Dec 25 21:51 . drwxr-x--x. 5 root abrt 4.0K Dec 25 21:50 .. -rw-------. 1 root root 6 Dec 25 21:50 analyzer -rw-------. 1 root root 6 Dec 25 21:50 architecture -rw-------. 1 root root 2.9K Dec 25 21:50 backtrace -rw-------. 1 root root 6 Dec 25 21:50 component -rw-------. 1 root root 1 Dec 25 21:50 count -rw-------. 1 root root 0 Dec 25 21:50 event_log -rw-------. 1 root root 25 Dec 25 21:50 kernel -rw-------. 1 root root 76 Dec 25 21:50 kernel_tainted_long -rw-------. 1 root root 3 Dec 25 21:50 kernel_tainted_short -rw-------. 1 root root 10 Dec 25 21:50 last_occurrence -rw-------. 1 root root 135 Dec 25 21:50 machineid -rw-------. 1 root root 131 Dec 25 21:50 not-reportable -rw-------. 1 root root 393 Dec 25 21:50 os_info -rw-------. 1 root root 38 Dec 25 21:50 os_release -rw-------. 1 root root 73 Dec 25 21:50 reason -rw-------. 1 root root 4 Dec 25 21:50 runlevel -rw-------. 1 root root 10 Dec 25 21:50 time -rw-------. 1 root root 6 Dec 25 21:50 type -rw-------. 1 root root 1 Dec 25 21:50 uid -rw-------. 1 root root 5 Dec 25 21:50 username -rw-------. 1 root root 40 Dec 25 21:50 uuid -rw-------. 1 root root 33M Dec 25 07:38 vmcore -rw-------. 1 root root 35K Dec 25 07:38 vmcore-dmesg.txt
それぞれのファイルの詳細は https://gist.github.com/hiboma/431d0a5e3e8fe8a1a2b699a71e61abf9 にまとめた。vmcore が取れていれば crash を使って原因の解析ができる
vmcore が残る
ところで /var/crash 以下にも kdump が採取した vmcore が残っている
# /var/crash $ sudo ls -hali /var/crash/127.0.0.1-2016-12-25-07\:38\:42/vmcore 310061 -rw-------. 1 root root 33M Dec 25 07:38 /var/crash/127.0.0.1-2016-12-25-07:38:42/vmcore # /var/spool/abrtd にも残ってる $ sudo ls -hali /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42/vmcore 19216963 -rw-------. 1 root root 33M Dec 25 07:38 /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42/vmcore
vmcore のサイズが大きい場合に、内容が同じ vmcore が重複するのはもったいない。設定で回避できるだろうか?
abrtd にはクラッシュをレポートする機能 (libreport) もついている。次回以降でまとめる
