kdump配置

kexec是一個快速啓動機制,允許通過已經運行的內核的上下文啓動一個Linux內核,不需要經過BIOS。BIOS可能會消耗很多時間,特別是帶有衆多數量的外設的大型服務器。這種辦法可以爲經常啓動機器的開發者節省很多時間。

kdump是一個新的,而且非常可信賴的內核崩潰轉儲機制。崩潰轉儲數據可以從一個新啓動的內核的上下文中獲取,而不是從已經崩潰的內核的上下文。當系統崩潰時,kdump使用kexec啓動到第二個內核。第二個內核通常叫做捕獲內核(capture kernel),以很小內存啓動,並且捕獲轉儲鏡像。

第一個內核保留了內存的一部分,第二個內核可以用來啓動。注意,在啓動時,kdump保留了一定數量的重要的內存,這改變了紅帽企業Linux 5最小內存需求。爲了計算系統需要的真正最小內存,可以參看 http://www.RedHat.com/rhel/details/limits/ 上列出的最小內存需求,加上kdump使用的內存數量,以決定真正的最小內存的需求。

因爲第一個內核的內存內容已經被保留,所以kexec可以不經過BIOS,啓動捕獲內核。這是內核崩潰轉儲的根本。


怎樣配置kdump

1.確認kexec-tools已經安裝:

#rpm -q kexec-tools

2.確認kernel-debuginfo和其支持包kernel-debuginfo-common已經安裝

#rpm -qa|grep kernel

下載地址http://debuginfo.centos.org/6/x86_64/

3.配置/etc/kdump.conf文件,指定vmcore將被轉儲的路徑。可以通過scp拷貝到另一個服務器,也可以是裸設備,或者本地的文件系統。

path /var/crash

4.修改/etc/sysctl.conf文件添加以下內容:

vm.panic_on_oom = 1

kernel.panic_on_unrecovered_nmi = 0

kernel.unknown_nmi_panic = 0

kernel.panic_on_oops = 1


5.修改一些啓動參數,爲捕獲很保留一塊內存。對於i386和x86_64架構,編輯/etc/grub.conf,在內核行的末尾添加

ro root=LABEL=/1 rhgb quiet crashkernel=128M@32M

下面是一個帶有kdump選項的/etc/grub.conf文件:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You do not have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /, eg.
#          root (hd0,0)
#          kernel /boot/vmlinuz-version ro root=/dev/hda1
#          initrd /boot/initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Client (2.6.17-1.2519.4.21.el5)
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.17-1.2519.4.21.el5 ro root=LABEL=/ rhgb quiet crashkernel=128M@16M
        initrd /boot/initrd-2.6.17-1.2519.4.21.el5.img
6.修改之後,重啓系統。128M內存(從16M開始)不被正常的系統使用,爲捕獲內核保留。注意,free -m的輸出會顯示內存比不加參數時少了128M,這就是我們所期望的。

注意:可以使用小於128M,但是隻使用64M做測試被證實是不可靠的。

在/boot/grub/menu.lst/中需要添加這樣的參數,即crashkernel=X@Y,其中X是轉儲空間大小(確切的講,是轉儲文件的最大大小),Y是轉儲的內存偏移。各種參考資料,包括官方給出的資料都是填寫128M@16M,但是有的時候,16M偏移的內存已經被佔用。這個時候,需要改成32M,相應的,在make menuconfig 時候的編譯選項CONFIG_PHYSICAL_START=0x1000000 也需要改成0x2000000。發生內存衝突時候,kdump服務起不來,報錯是缺少crashkernel這個啓動選項,而官方的文檔中的解決方法只是說重新檢查這個啓動文件的書寫,真是很迷惑人。我檢查很多次都沒有發現問題,最終搜索一下午,在網上的一個bug報告中發現了這個問題,唬人呀!


7.現在,保留內存已經設置了,打開kdump初始腳本,啓動服務:

#  chkconfig kdump on
#  service kdump start
8.可以通過kexec加載內核鏡像,讓系統準備捕獲一個崩潰時產生的vmcore。可以通過sysrq強制系統崩潰:

# echo "c" > /proc/sysrq-trigger
這造成kernel panic,緊跟着系統重啓kdump內核。當啓動進程進入到啓動kdump服務器時,vmcore將會被拷貝到你在/etc/kdump.conf文件中指定的位置。


注意:

終端frame-buffer和X將運行不正常。在運行一些類似於在內核配置上添加了"vga=791"或者運行X的系統,在通過kexec啓動內核時,終端顯示將不清楚。記住,kdump內核仍舊能夠創建轉儲。當系統重啓,顯示將會恢復到正常狀態。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章