Step 1: Configuring Kdump
1、首选安装工具
kexec-tools crash kernel-debuginfo
kernel-debuginfo工具需要开启本地yum源 CentOS-Debuginfo.repo，默认自带的源，没有请创建一个
[root@iZ2zeegg8kg0g6pantu49vZ ~]# vim /etc/yum.repos.d/CentOS-Debuginfo.repo
[base-debuginfo]
name=CentOS-7 - Debuginfo
baseurl=http://debuginfo.centos.org/7/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Debug-7
enabled=1 ##enabled默认0需要改为1
另外安装kernel-debuginfo 需要符合本地内核版本
[root@iZ2zeegg8kg0g6pantu49vZ ~]# uname -r
3.10.0-1127.8.2.el7.x86_64
如下请安装
yum install kexec-tools crash kernel-debuginfo-3.10.0-1127.8.2.el7
2、编译grub.conf
编辑/boot/grub/grub.conf或/boot/grub2/grub.cfg并添加“ crashkernel = 128M”命令行选项
linux16 /boot/vmlinuz-3.10.0-1127.8.2.el7.x86_64 root=UUID=5f56c9a9-0b5f-428b-b092-7cc41e7c4a93 ro crashkernel=auto
默认配置有crashkernel=auto
3、编辑kdump配置（可选）
接下来，考虑编辑kdump配置文件/etc/kdump.conf，主要看crash文件位置，默认path /var/crash
4、启动服务
systemctl start kdump.service
systemctl enable kdump.service
注意事项：
- 上面显示的参数保留128MB的物理内存。该保留的内存用于预加载和运行捕获内核。
- 初始化脚本负责在系统引导时预加载捕获内核。
- 建议出于测试目的，设置串行控制台或切换到运行级别3（初始3）。原因是，如果您处于X或帧缓冲模式，则kdump不会重置控制台，并且在系统崩溃后控制台上可能看不到任何消息。在捕获过程中，您可能还会在图形模式下看到屏幕损坏。
- 捕获故障转储会花费很长时间，尤其是在系统具有大量内存的情况下。耐心点。捕获转储后，系统将重新启动。
Step 2: Capturing the Dump
通常，内核panic（）会触发引导进入捕获内核，但是出于测试目的，可以通过以下方式之一来模拟触发。
启用SysRq，然后通过/proc界面 触发紧急情况
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
通过插入一个调用panic（）的模块来触发。
系统将启动进入捕获内核。内核转储将自动保存在其中/var/crash/<dumpdir>，系统将重新引导回常规内核。转储目录的名称将取决于崩溃的日期和时间。例如，/var/crash/2006-02-17-17:02/vmcore
Step 3: Dump Analysis
系统从恢复崩溃中恢复后，您可能希望使用该crash工具分析内核转储文件。
crash /var/crash/2009-07-17-10\:36/vmcore /usr/lib/debug/lib/modules/`uname -r`/vmlinux
其中各项参数的意义为：
KERNEL: 表示调试用内核的位置和版本信息；
DUMPFILE: 表示所分析的内存转储镜像
CPUS: 表示本机的 CPU 数目；
DATE: 表示内核崩溃发生的时间；
UPTIME: 表示内核已正常运行的时间；
LOAD AVERAGE: 表示内核崩溃时系统的负载；
TASKS: 表示内核崩溃时系统运行的任务数；
NODENAME: 表示内核崩溃的机器的主机名；
RELEASE: 表示内核的发布版本；
VERSION: 表示内核的其他版本信息
MACHINE: 表示 CPU 的架构和主频信息；
MEMORY: 表示发生内核崩溃的系统的内存大小；
PANIC: 表示内核崩溃的类型； 这里可能有 SysRq（即通过系统请求造
成的内核崩溃，如上面测试用的命令即是）， Oops（表示内核
发生了不可预期的或不正确的行为，这时会杀死相应的进程，
内核可能恢复正常，也可能处于一种不确定的状态，并进而导
致内核的 Panic）， 以及 Panic（ 内核崩溃，即发生了严重且不可
修复的错误， 如发生了非法的地址访问， 强制加载或卸载内核
模块，以及硬件错误等等）。
PID: 表示导致内核崩溃的进程号；
COMMAND: 表示导致内核崩溃的进程名称
TASK: 表示导致内核崩溃的进程访问的内存地址；
CPU: 表示导致内核崩溃的进程占用的 CPU 数目；
STATE: 表示导致内核崩溃的进程的运行状态。
以上信息可用于初步分析内核崩溃的原因，内核态有三种出错情况，分别是 bug, oops
和 panic。 bug 属于轻微错误， oops 代表某一用户进程出现错误，需要杀死用户进程。
这时如果用户进程占用了某些信号锁，所以这些信号锁将永远不会得到释放，这会导致
系统潜在的不稳定性。 panic 是严重错误，代表整个系统崩溃。 深入的分析需要使用更
多的命令进行追踪和查找.
Crash 常用的命令有如下几个：
help #查看命令的帮助信息， 也可用 man 命令
h #查看历史命令，相当于 shell 下的 history
log #该命令用于打印出内存的日志信息
bt #该命令用于获取当前线程的调用堆栈
foreach bt #该命令用于获取所有线程的调用堆栈
ps #该命令用于查看内核崩溃时的进程信息
vm #该命令用于查看当前的内核上下文的虚拟内存信息
files #该命令用于查看当前的内核上下文中打开的文件
exit or q #退出 Crash
