鞠婧祎视频素材,刘涛直播视频

一、什么是kdump

kdump 是一種先進(jìn)的基于 kexec 的內(nèi)核崩潰轉(zhuǎn)儲(chǔ)機(jī)制。當(dāng)系統(tǒng)崩潰時(shí)，kdump 使用 kexec 啟動(dòng)到第二個(gè)內(nèi)核。第二個(gè)內(nèi)核通常叫做捕獲內(nèi)核，以很小內(nèi)存啟動(dòng)以捕獲轉(zhuǎn)儲(chǔ)鏡像。第一個(gè)內(nèi)核保留了內(nèi)存的一部分給第二內(nèi)核啟動(dòng)用。由于 kdump 利用 kexec 啟動(dòng)捕獲內(nèi)核，繞過了 BIOS，所以第一個(gè)內(nèi)核的內(nèi)存得以保留。這是內(nèi)核崩潰轉(zhuǎn)儲(chǔ)的本質(zhì)。

kdump 需要兩個(gè)不同目的的內(nèi)核，生產(chǎn)內(nèi)核和捕獲內(nèi)核。生產(chǎn)內(nèi)核是捕獲內(nèi)核服務(wù)的對(duì)像。捕獲內(nèi)核會(huì)在生產(chǎn)內(nèi)核崩潰時(shí)啟動(dòng)起來，與相應(yīng)的 ramdisk 一起組建一個(gè)微環(huán)境，用以對(duì)生產(chǎn)內(nèi)核下的內(nèi)存進(jìn)行收集和轉(zhuǎn)存。

二、kdump執(zhí)行流程

為了更容易理解這里我以三張圖展示下kdump的執(zhí)行流程，首先看的是Vivek Goyal 的PPT中兩幅圖

下面兩副圖是來自于IBM技術(shù)論壇上的rhel6.2和suse11下的執(zhí)行流程圖

rhel6.2的執(zhí)行流程

suse11下的執(zhí)行流程

三、kdump 的安裝及測(cè)試

1、相關(guān)包的安裝

這里以centos6.x下的安裝為例

kexec-tools
kexec package
kernel-debuginfo  //需單獨(dú)另外安裝，yum源里沒有
crash analysis package
安裝命令如下
# yum -y install kernel kexec-tools

如果需要圖形化的配置工具，還要安裝system-config-kdump包。

2、grub內(nèi)核配置

編輯 /boot/grub/grub.conf 配置文件，修改用到的引導(dǎo)部分，加入crashkernel部分，

參數(shù)格式是：
crashkernel=nn[KMG]@ss[KMG]
nn表示要為crashkernel預(yù)留多少內(nèi)存
ss表示為crashkernel預(yù)留內(nèi)存的起始位置

示例如下：

root (hd0,0)
kernel /vmlinuz-2.6.18-92.el5 ro root=LABEL=/ crashkernel=256M@16M
initrd /initrd-2.6.18-92.el5.img
或
root (hd0,0)
kernel /vmlinuz-2.6.32-431.17.1.el6.x86_64 ro root=/dev/mapper/vg_centos-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M@48M rd_LVM_LV=vg_centos/lv_root  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32-431.17.1.el6.x86_64.img

修改完成并重啟后，可以通過cat /proc/cmdline 查看kernel 啟動(dòng)配置選項(xiàng) ，此處修改重啟后我的/proc/cmdline文件為：

ro root=/dev/mapper/vg_centos-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_centos/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M@48M rd_LVM_LV=vg_centos/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet

注：在centos 7.x上，開始使用grub2 引導(dǎo)，配置路徑文件為

UEFI引導(dǎo)時(shí)
/boot/efi/EFI/centos/grub.cfg
BIOS引導(dǎo)時(shí)
/boot/grub2/grub.cfg

小技巧：修改該值可以直接使用grubby命令進(jìn)行修改grub.cfg文件（該命令同樣適用于grub2和UEFI引導(dǎo)的情況）如：

[root@localhost boot]# grubby --update-kernel=DEFAULT --args=crashkernel=128M

3、啟動(dòng)kdump服務(wù)

在centos6.x上可以使用下面的命令啟動(dòng)kdump服務(wù)（在suse11企業(yè)版中，kdump服務(wù)名為boot.kdump）

# /etc/init.d/kdump start
Starting kdump: [FAILED]

發(fā)現(xiàn)啟動(dòng)失敗，通過查看/var/log/message日志，可以發(fā)現(xiàn)如下內(nèi)容：

kdump: No crashkernel parameter specified for running kernel

注：

a、這里我嘗試過grub.cfg里配置crashkernel=auto 、crashkernel=128M@16M，啟動(dòng)失敗，后來看到oracle 站點(diǎn)上的示例，改為crashkernl=128M@48M后，發(fā)現(xiàn)kdump服務(wù)可以啟動(dòng)成功，而且每次修改后都需要reboot重啟系統(tǒng)，后來查了下手動(dòng)指定@xxxM的時(shí)候可能會(huì)失敗的原因，是因?yàn)槿绻诙€(gè)內(nèi)核與第一個(gè)內(nèi)核在地址空間上有重疊的話，會(huì)導(dǎo)致第二個(gè)內(nèi)核啟動(dòng)失敗，所以此處可以直接設(shè)置為crashkernel=128M。

b、crashkernle 的值也要根據(jù)具體自己的實(shí)際物理內(nèi)存大小靈活調(diào)整，如實(shí)際物理內(nèi)存實(shí)在足夠大，可以設(shè)置為256M、512M 。

c、crashkernel 的值設(shè)置后，使用free -m 要看時(shí)，會(huì)發(fā)現(xiàn)內(nèi)存少了@ 號(hào)前面配置的值大小。如，我配置的是crashkernel@128M@48M，就會(huì)少128M內(nèi)存。

再次啟動(dòng)kdump服務(wù)

[root@361way sysconfig]# /etc/init.d/kdump restart
Stopping kdump:                                            [  OK  ]
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.32-431.17.1.el6.x86_64kdump.img
Starting kdump:                                            [  OK  ]

會(huì)發(fā)現(xiàn)會(huì)在/boot 目錄下新增一個(gè)以kdump結(jié)尾的內(nèi)核文件。

[root@361way boot]# ls
config-2.6.32-431.17.1.el6.x86_64  grub                                        lost+found                             System.map-2.6.32-431.17.1.el6.x86_64
config-2.6.32-431.el6.x86_64       initramfs-2.6.32-431.17.1.el6.x86_64.img    memtest86+-4.10                        System.map-2.6.32-431.el6.x86_64
efi                                initramfs-2.6.32-431.el6.x86_64.img         symvers-2.6.32-431.17.1.el6.x86_64.gz  vmlinuz-2.6.32-431.17.1.el6.x86_64
elf-memtest86+-4.10                initrd-2.6.32-431.17.1.el6.x86_64kdump.img  symvers-2.6.32-431.el6.x86_64.gz       vmlinuz-2.6.32-431.el6.x86_64

注：在centos 7.x 上開始使用systemd進(jìn)行服務(wù)進(jìn)程的啟動(dòng)管理，啟動(dòng)服務(wù)折方法需要通過以下方法執(zhí)行

# systemctl enable kdump.service    //配置服務(wù)的開機(jī)自啟動(dòng)
# systemctl start kdump.service       //啟動(dòng)kdump服務(wù)

4、測(cè)試模擬kdump

配置完成后，需要重啟機(jī)器加載新的內(nèi)核。可以使用下面的方法默認(rèn)kdmp生成

# service kdump on   //設(shè)置服務(wù)開機(jī)自啟動(dòng)
# reboot            //重啟系統(tǒng)使剛剛所有的修改生效
# sync
# echo c > /proc/sysrq-trigger

執(zhí)行后，機(jī)器會(huì)重啟，重啟進(jìn)入系統(tǒng)后，會(huì)在/var/crash 目錄生成kdmp文件，文件內(nèi)容可以通過crash命令進(jìn)行分析，后面會(huì)對(duì)此進(jìn)行專門的介紹。

四、kdump的高級(jí)配置

和kdump相關(guān)的配置文件有兩個(gè)：一個(gè)是/etc/sysconfig/kdump，該文件內(nèi)的內(nèi)容一般無需修改－－網(wǎng)上一些技術(shù)站上在kdump服務(wù)啟動(dòng)不成功時(shí)修改這里，這里提示下，如果是通過yum源正常安裝的，該文件無需修改；一個(gè)是/etc/kdump.conf 。這里指的高級(jí)配置主機(jī)是/etc/kdump.conf ，該配置文件的可配置選項(xiàng)可通過man 5 kdump.conf 獲取幫助，這里只列舉下常用到的部分：

1、設(shè)置kdump文件成生的位置

控制路徑的主要有兩部分：

#raw /dev/sda5
#ext4 /dev/sda3
#ext4 LABEL=/boot
#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
#nfs my.server.com:/export/tmp
#ssh user@my.server.com
path /var/crash

前面的部分用于設(shè)置存儲(chǔ)的設(shè)備或分區(qū)位置－－可以是raw裸設(shè)備、本地分區(qū)、網(wǎng)絡(luò)路徑在本地的掛載點(diǎn)或通過ssh傳輸，path則是相對(duì)的存儲(chǔ)路徑。如我們通過nfs 將遠(yuǎn)程的一個(gè)分區(qū)掛載到本地的/mnt分區(qū)下，kdump文件就存儲(chǔ)在/mnt/var/crash/下。默認(rèn)上面的部分不設(shè)置就是相對(duì)根分區(qū)的相對(duì)路徑，即/var/crash 。

需要特別指出的是，如果使用ssh進(jìn)行傳輸，需要配置key認(rèn)證，使用/etc/init.d/kdump propagate即可配置ssh認(rèn)證傳輸，如下：

kdump.conf中指定ssh網(wǎng)絡(luò)傳輸
ssh root@192.168.0.100/data/
執(zhí)行下面的命令會(huì)配置本機(jī)到192.168.0.100主機(jī)的key認(rèn)證傳輸
# service kdump propagate
Generating new ssh keys… done.
The authenticity of host '192.168.0.100 (192.168.0.100)' can't be established.
RSA key fingerprint is 31:c2:d8:b6:eb:2e:03:64:cd:ba:56:e9:49:6e:5d:6c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.100' (RSA) to the list of known hosts.
root@192.168.0.100's password:
/root/.ssh/kdump_id_rsa.pub has been added to ~root/.ssh/authorized_keys2 on
192.168.0.100

按照上面的配置，當(dāng)有kdump生成時(shí)，會(huì)通過scp傳輸存儲(chǔ)在192.168.0.100主機(jī)的/data/var/crash 目錄下。

2、core_collector控制

該處是信息收集大小的關(guān)鍵，主要用到makedumpfile命令，centos 上的默認(rèn)配置如下：

core_collector makedumpfile -c --message-level 1 -d 31

-c 表示啟動(dòng)zlib進(jìn)行數(shù)據(jù)壓縮

–message-level 指定了信息收集的級(jí)別，1為只打印process indicator 日志信息，默認(rèn)值為7，具體見下表

Message | progress    common    error     debug     report
Level   | indicator   message   message   message   message
---------+------------------------------------------------------
      0 |
      1 |     X
      2 |                X
      4 |                          X
    * 7 |     X          X         X
      8 |                                    X
     16 |                                              X
     31 |     X          X         X         X         X

-d 指定了kdump的過濾級(jí)別，具體見下表

       |         cache    cache
 Dump  |  zero   without  with     user    free
 Level |  page   private  private  data    page
-------+---------------------------------------
    0  |
    1  |   X
    2  |           X
    4  |           X       X
    8  |                           X
   16  |                                    X
   31  |   X        X      X       X        X

31表示過濾掉以上五種全部信息，這樣kdump生成的速度就會(huì)更快，生成的vmcore文件也會(huì)較小。如果此處使用值0 ，表示不過濾任何信息，在kdump生成時(shí)，會(huì)記錄主機(jī)當(dāng)前的所有信息。這就是為什么在kdump生成時(shí)，有些主機(jī)只有幾十M大小生成，有些主機(jī)確有幾十 G大小的原因。更多用法可以查看makedumpfile命令的幫助文檔。

3、指定default配置

該處的配置，我也參考了網(wǎng)上的一些配置，一些技術(shù)文檔上使用的是defult reboot選項(xiàng)，而默認(rèn)的是defult shell ，兩者之間的區(qū)別是：

reboot: If the default action is reboot simply reboot the system and loose the core that you are  trying to retrieve.
shell:  If the default action is shell, then drop to an hush session inside the initramfs from where you can try to record the core manually.Exiting this shell reboots the system.

在查看/usr/share/doc/kexec-tools-2.0.0/kexec-kdump-howto.txt幫助手冊(cè)中的解釋更容易理解一些，如下：

reboot --> reboot the system.
shell  --> drop to a shell with-in initrd. A user can try to capture the
           vmcore manually.

從這個(gè)解釋可以看到選擇shell 可以手工的DIY一些東西，而選擇reboot 會(huì)在kdump生成后簡(jiǎn)單直接的reboot 系統(tǒng)。除了上在兩個(gè)選項(xiàng)，還會(huì)poweroff 、halt 可選，如果不是技術(shù)研究的目錄，在生產(chǎn)環(huán)境上我想誰不會(huì)選擇kdump生成后讓系統(tǒng)掛起吧。

除上面三處之外，還有其他配置部分，如debug_mem 的配置等。具體可以看kdump.conf 的man 結(jié)果。

五、crash進(jìn)行結(jié)果分析

crash包需要yum -y install crash 單獨(dú)安裝過，另外crash 命令需要依賴kernel-debuginfo 包（該包又依賴kernel-debuginfo-common包），該包的下載地址：http://debuginfo.centos.org/6/x86_64/ 。下載前先要確認(rèn)下自己主機(jī)的內(nèi)核版本。我在測(cè)試機(jī)上是通過下面的命令執(zhí)行的：

# uname -r
2.6.32-431.17.1.el6.x86_64
# wget http://debuginfo.centos.org/6/x86_64/kernel-debuginfo-common-x86_64-2.6.32-431.17.1.el6.x86_64.rpm
# wget http://debuginfo.centos.org/6/x86_64/kernel-debuginfo-2.6.32-431.17.1.el6.x86_64.rpm

下載完成后，通過rpm -ivh將這兩個(gè)包安裝。然后通過下面的命令進(jìn)行crash分析

# pwd
/var/crash/127.0.0.1-2014-09-16-14:35:49
# crash /usr/lib/debug/lib/modules/2.6.32-431.17.1.el6.x86_64/vmlinux vmcore
crash 6.1.0-5.el6
Copyright (C) 2002-2012  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
      KERNEL: /usr/lib/debug/lib/modules/2.6.32-431.17.1.el6.x86_64/vmlinux
    DUMPFILE: vmcore  [PARTIAL DUMP]
        CPUS: 1
        DATE: Tue Sep 16 22:35:49 2014
      UPTIME: 00:05:33
LOAD AVERAGE: 0.00, 0.00, 0.00
       TASKS: 175
    NODENAME: localhost.localdomain
     RELEASE: 2.6.32-431.17.1.el6.x86_64
     VERSION: #1 SMP Wed May 7 23:32:49 UTC 2014
     MACHINE: x86_64  (3398 Mhz)
      MEMORY: 1 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)
         PID: 1412
     COMMAND: "bash"
        TASK: ffff88003d0b2040  [THREAD_INFO: ffff88003c33c000]
         CPU: 0
       STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 1412   TASK: ffff88003d0b2040  CPU: 0   COMMAND: "bash"
 #0 [ffff88003c33d9e0] machine_kexec at ffffffff81038f3b
 #1 [ffff88003c33da40] crash_kexec at ffffffff810c59f2
 #2 [ffff88003c33db10] oops_end at ffffffff8152b7f0
 #3 [ffff88003c33db40] no_context at ffffffff8104a00b
 #4 [ffff88003c33db90] __bad_area_nosemaphore at ffffffff8104a295
 #5 [ffff88003c33dbe0] bad_area at ffffffff8104a3be
 #6 [ffff88003c33dc10] __do_page_fault at ffffffff8104ab6f
 #7 [ffff88003c33dd30] do_page_fault at ffffffff8152d73e
 #8 [ffff88003c33dd60] page_fault at ffffffff8152aaf5
    [exception RIP: sysrq_handle_crash+22]
    RIP: ffffffff8134b516  RSP: ffff88003c33de18  RFLAGS: 00010096
    RAX: 0000000000000010  RBX: 0000000000000063  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: 0000000000000063
    RBP: ffff88003c33de18   R8: 0000000000000000   R9: ffffffff81645da0
    R10: 0000000000000001  R11: 0000000000000000  R12: 0000000000000000
    R13: ffffffff81b01a40  R14: 0000000000000286  R15: 0000000000000004
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #9 [ffff88003c33de20] __handle_sysrq at ffffffff8134b7d2
#10 [ffff88003c33de70] write_sysrq_trigger at ffffffff8134b88e
#11 [ffff88003c33dea0] proc_reg_write at ffffffff811f2f1e
#12 [ffff88003c33def0] vfs_write at ffffffff81188c38
#13 [ffff88003c33df30] sys_write at ffffffff81189531
#14 [ffff88003c33df80] system_call_fastpath at ffffffff8100b072
    RIP: 00000036e3adb7a0  RSP: 00007fff22936c10  RFLAGS: 00010206
    RAX: 0000000000000001  RBX: ffffffff8100b072  RCX: 0000000000000400
    RDX: 0000000000000002  RSI: 00007fab7908b000  RDI: 0000000000000001
    RBP: 00007fab7908b000   R8: 000000000000000a   R9: 00007fab79084700
    R10: 00000000ffffffff  R11: 0000000000000246  R12: 0000000000000002
    R13: 00000036e3d8e780  R14: 0000000000000002  R15: 00000036e3d8e780
    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b
crash>

上面，只是簡(jiǎn)單的通過打印堆棧信息，顯示主機(jī)在出現(xiàn)kdump生成時(shí)，pid 為1412的bash進(jìn)程操作。從上面的顯示信息中也簡(jiǎn)單的看到有 write_sysrq_trigger 函數(shù)觸發(fā)。crash在定位問題原因時(shí)，為我們提供了下面的命令：

crash> ?
*              files          mach           repeat         timer
alias          foreach        mod            runq           tree
ascii          fuser          mount          search         union
bt             gdb            net            set            vm
btop           help           p              sig            vtop
dev            ipcs           ps             struct         waitq
dis            irq            pte            swap           whatis
eval           kmem           ptob           sym            wr
exit           list           ptov           sys            q
extend         log            rd             task
crash version: 6.1.0-5.el6   gdb version: 7.3.1
For help on any command above, enter "help <command>".
For help on input options, enter "help input".
For help on output options, enter "help output".

由于crash的內(nèi)容也較多，以下是針對(duì)suse下信息提到的一個(gè)腳本：

mkdir -p /tmp/kdump
crash $*   <<EOF  >/tmp/kdump/kdumpoutput.txt 2>&1
log >/tmp/kdump/log.txt
sys >/tmp/kdump/sys.txt
bt >/tmp/kdump/bt.tx
foreach bt >/tmp/kdump/all-bt.txt
foreach files>/tmp/kdump/all-files.txt
ps >/tmp/kdump/ps.txt
swap>/tmp/kdump/swap.txt
runq >/tmp/kdump/runq.txt
mount >/tmp/kdump/mount.txt
net >/tmp/kdump/net.txt
dev >/tmp/kdump/dev.txt
dev -i >/tmp/kdump/dev-i.txt
dev -p >/tmp/kdump/dev-p.txt
files >/tmp/kdump/files.txt
irq >/tmp/kdump/irq.txt
kmem -f >/tmp/kdump/pmemory.txt
kmem -i >/tmp/kdump/memory.txt
mach >/tmp/kdump/mach.txt
mod >/tmp/kdump/modules.txt
net -s >/tmp/kdump/net-s.txt
ps -t >/tmp/kdump/ps-t.txt
ps -c >/tmp/kdump/ps-c.txt
sig >/tmp/kdump/sig.txt
set >/tmp/kdump/set.txt
task >/tmp/kdump/task.txt
foreach task >/tmp/kdump/all-task.txt
sym -l >/tmp/kdump/sys-l.txt
sym -M >/tmp/kdump/sys-M.txt
quit
EOF

使用下面的腳本按如下方法執(zhí)行：

# getcoreinfo.sh -f vmlinux-3.0.76-0.11-default.gz vmlinux-3.0.76-0.11-default.debug vmcore

六、kdump涉及的sysctl 配置

查閱了網(wǎng)上很多有關(guān)kdump的資料，發(fā)現(xiàn)在配置kdump時(shí)，對(duì)sysctl.conf 內(nèi)的一些配置也進(jìn)行了調(diào)整。這里也列舉下，可以根據(jù)具體的情況酌情進(jìn)行修改。

kernel.sysrq=1
kernel.unknown_nmi_panic=1
kernel.softlockup_panic=1

kernel.sysrq=1，如果通過/proc文件配置，上面的配置等價(jià)于echo 1 > /proc/sys/kernel/sysrq ，打開sysrq鍵的功能以后，有終端訪問權(quán)限的用戶將會(huì)擁有一些特別的功能。如果系統(tǒng)出現(xiàn)掛起的情況或在診斷一些和內(nèi)核相關(guān)，
使用這些組合鍵能即時(shí)打印出內(nèi)核的信息。因此，除非是要調(diào)試，解決問題，一般情況下，不要打開此功能。如果一定要打開，請(qǐng)確保你的終端訪問的安全性。具體可以參看百度百科上給出的解釋。

kernel.unknown_nmi_panic=1 ,如果系統(tǒng)已經(jīng)是處在Hang的狀態(tài)的話，那么可以使用NMI按鈕來觸發(fā)Kdump。開啟這個(gè)選項(xiàng)可以：echo 1 > /proc/sys/kernel/unknown_nmi_panic 需要注意的是，啟用這個(gè)特性的話，是不能夠同時(shí)啟用NMI_WATCHDOG的！否則系統(tǒng)會(huì)Panic！

kernel.softlockup_panic=1,其對(duì)應(yīng)的是/proc/sys/kernel/softlockup_panic的值，值為1可以讓內(nèi)核在死鎖或者死循環(huán)的時(shí)候可以宕機(jī)重啟。如果你的機(jī)器中安裝了kdump，在重啟之后，你會(huì)得到一份內(nèi)核的core文件，這時(shí)從core文件中查找問題就方便很多了，而且再也不用手動(dòng)重啟機(jī)器了。如果你的內(nèi)核是標(biāo)準(zhǔn)內(nèi)核的話，可以通過修改/proc/sys/kernel/softlockup_thresh來修改超時(shí)的閾值，如果是CentOS內(nèi)核的話，對(duì)應(yīng)的文件是/proc/sys/kernel/watchdog_thresh。

除此之外，一些站點(diǎn)上還會(huì)建議修改開啟oops painc的功能，這個(gè)也具體根據(jù)實(shí)際需要修改吧。

參考頁面：IBM developer Works技術(shù)論壇

Kdump & Crash 學(xué)習(xí)筆記

PS:自動(dòng)配置kdump的功能，我已經(jīng)腳本化，放在了我的github上。

后記：

在后面使用中發(fā)現(xiàn)有出現(xiàn)kdump與現(xiàn)有模塊沖突導(dǎo)致一直無法生成kdump的情況，這里的是VCS 的vxfs與fusion io的iomemory-vsl4模板與kdump沖突?？梢酝ㄟ^blacklist參數(shù)將其在/etc/kdump.conf中屏蔽－－－suse下為/etc/sysconfig/kdump。如下：

blacklist vxfs
blacklist iomemory-vsl4

關(guān)于blacklist參數(shù)，redhat原廠工程師給予的解釋是：blacklist參數(shù)的作用是當(dāng)觸發(fā)kdump時(shí)，在進(jìn)入第二內(nèi)核（一般稱為capture kernel或kdump kernel）時(shí)不加載指定的模塊。這個(gè)參數(shù)只會(huì)在發(fā)生kdump時(shí)起作用，不會(huì)影響系統(tǒng)正常運(yùn)行。

還需要注意的是在涉及到配置文件變動(dòng)時(shí)，如生成路徑修改或blacklist內(nèi)容增加，都需要重新生成kdump的RAM文件，不然其在發(fā)生問題時(shí)還是使用老的img RAM文件，該文件在/boot下以kdump.img結(jié)尾的文件就是：

#ls -l /boot
total 35024
-rw-r--r--. 1 root root   105195 Nov 11  2013 config-2.6.32-431.el6.x86_64
drwxr-xr-x. 3 root root     4096 Sep 15 12:12 efi
drwxr-xr-x. 2 root root     4096 Sep 22 16:44 grub
-rw-------. 1 root root 17135661 Sep 15 12:25 initramfs-2.6.32-431.el6.x86_64.img
-rw-------  1 root root 11743320 Sep 22 16:35 initrd-2.6.32-431.el6.x86_64kdump.img
drwx------. 2 root root    16384 Sep 15 12:01 lost+found
-rw-r--r--. 1 root root   193758 Nov 11  2013 symvers-2.6.32-431.el6.x86_64.gz
-rw-r--r--. 1 root root  2518236 Nov 11  2013 System.map-2.6.32-431.el6.x86_64
-rwxr-xr-x. 1 root root  4128944 Nov 11  2013 vmlinuz-2.6.32-431.el6.x86_64

遇到配置變動(dòng)時(shí)，可以將/boot下的initrd-`uname -r`kdump.img文件mv走，再通過重啟kdump服務(wù)生成新的kdump.img文件。如下：

注：SUSE下重新生成使用的是/etc/init.d/boot.kdump restart 命令。

在kdump重新生成后，最好重啟下主機(jī)。另一個(gè)kdump配置里需要注意的參數(shù)是：MKDUMPRD_ARGS=”–allow-missing” ，增加完該參數(shù)，會(huì)在主機(jī)每次啟動(dòng)時(shí)自動(dòng)檢查kdump配置并重新rebuild kdump.img文件。

kdump壓縮

下面的命令是壓縮vmcore的，請(qǐng)嘗試操作下面的命令看是否可以壓縮（可能比較耗費(fèi)時(shí)間和部分系統(tǒng)資源），實(shí)際原理就是由原crash級(jí)別，改為級(jí)別31：

makedumpfile -c -d 31 -x vmlinux-3.0.76-0.11-default.debug /xx/xx/vmcore /xx/shorter-vmcore

還在記得/xx/shorter-vmcore 存放目錄有足夠大的空間。

本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊舉報(bào)。

中文字幕理论片,69视频免费在线观看,亚洲成人app,国产1级毛片,刘涛最大尺度戏视频,欧美亚洲美女视频,2021韩国美女仙女屋vip视频

一、什么是kdump

二、kdump執(zhí)行流程

三、kdump 的安裝及測(cè)試

四、kdump的高級(jí)配置

五、crash進(jìn)行結(jié)果分析