linu 主机利用crash分析 var crash 下的vmcore 的dump分析

合集下载

linuxcrash用法

linuxcrash用法Linux Crash 是一个用于分析和调试Linux 操作系统崩溃的工具。

它提供了强大的功能和命令，帮助系统管理员和开发人员快速诊断和解决系统崩溃问题。

本文将一步一步回答关于Linux Crash 的使用方法和常见问题。

第一步：安装Linux Crash使用Linux Crash 之前，首先需要安装该工具。

大多数Linux 发行版都有一个软件仓库，可以从中安装Linux Crash。

不过，你也可以从源代码进行安装。

在终端中运行以下命令来安装Crash ：sudo apt-get install crash或者，从源代码安装：git clone git:github/crash-utility/crash.gitcd crashmakesudo make install安装完成后，你可以在终端中输入crash 命令来启动Linux Crash 。

第二步：收集崩溃转储文件在使用Linux Crash 之前，你需要一个崩溃的转储文件。

转储文件包含了崩溃时系统的内存状态和调试信息，以便于Crash 进行分析。

通常情况下，转储文件位于/var/crash 目录下。

你可以使用以下命令来查找转储文件：ls /var/crash如果没有找到转储文件，你可以尝试使用以下命令来生成一个崩溃：echo c > /proc/sysrq-trigger这会触发一个崩溃，并生成一个转储文件。

第三步：分析崩溃转储文件当你有了一个崩溃的转储文件后，你可以使用Crash 工具来分析它。

在终端中输入以下命令：crash /path/to/dumpfile其中，/path/to/dumpfile 是你的转储文件的路径。

Crash 会启动并加载转储文件。

第四步：使用Crash 命令来分析崩溃一旦Crash 启动并加载了转储文件，你可以使用各种Crash 命令来分析崩溃。

以下是一些常用的Crash 命令：1. bt：显示当前调用栈的回溯。

crashkernel参数

crashkernel参数（原创实用版）目录1.介绍 crashkernel 参数2.crashkernel 参数的作用3.使用 crashkernel 参数的方法4.crashkernel 参数的示例5.结论正文1.介绍 crashkernel 参数crashkernel 参数是 Linux 内核中的一个重要参数，主要用于在系统崩溃时进行内核转储，以便于对系统崩溃的原因进行分析和调试。

crashkernel 参数通常在系统启动时由内核自动设置，也可以通过手动编辑内核配置文件进行设置。

2.crashkernel 参数的作用crashkernel 参数的主要作用是在系统发生异常时，将内核的当前状态保存到一个文件中，以便于系统管理员或开发人员进行分析。

通过分析crashkernel 参数保存的内核状态，可以找到系统崩溃的原因，进而对系统进行调试和优化。

3.使用 crashkernel 参数的方法要使用 crashkernel 参数，首先需要确保系统内核已经启用了crashkernel 支持。

接下来，可以通过以下两种方法使用 crashkernel 参数：（1）使用命令行工具：可以使用“crash”命令将 crashkernel 参数保存到一个文件中。

例如：```crash /path/to/crashkernel```（2）手动编辑内核配置文件：可以手动编辑内核配置文件（通常位于 /usr/src/linux/.config 或 /usr/src/linux-xx.xx/.config），将CRASH_DUMP_ON_ZERO_PANIC设置为y，并配置一个用于存储crashkernel 文件的路径。

例如：```CONFIG_CRASH_DUMP_ON_ZERO_PANIC=yCONFIG_CRASH_DUMP_DIR=/path/to/crashdumps```4.crashkernel 参数的示例以下是一个 crashkernel 参数的示例：```$ crash /path/to/crashkernel```上述命令将把系统当前的状态保存到/path/to/crashkernel文件中。

linux主机利用crash分析_var_crash_下的vmcore 的dump分析

当主机crash后，会在这个目录下生成vmcore，也就是dump，如何分析这个dump来定位宕机的原因呢?可以执行crash vmlinux /var/crash/127.0.0.1-2014-06-22-16:08:36 来进入分析模式（vnlinux这里要指定的）他会报错，原因应该是缺乏kernel-debuginfo包，我们安装下后再尝试：要想crash可以分析core-dump，必须要安装这三个包：安装完后，我们可以利用find / -name vmlinux上面的crash爆出了：报错，这是由于kernel-debuginfo-common-x86_64包的版本和本机内核版本不一致照成的。

（说下：要想使用crash，只要保证debuginfo的版本和你要分析的core的内核版本本机的kernel版本三者的版本必须一样，任意一个不一致都会导致不能分析dump）##选择包和版本#再选择show debug package找到debug包下载就可以了----------------------------------------然后安装一下：#安装包开始++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++至于我们怎么知道coredump的内核版本，可以cd /var/crash/127.0.0.1---------/然后执行strings vmcore |grep 'OSRELEASE'可以显示出vmcore的内核版本顺便附一下内核版本和系统版本的对应关系CentOS 6.0/RHEL6 Update 0 -------------------> 2.6.32-71CentOS 6.1/RHEL6 Update 1 -------------------> 2.6.32-131CentOS 6.2/RHEL6 Update 2 -------------------> 2.6.32-220CentOS 6.3/RHEL6 Update 3 -------------------> 2.6.32-279CentOS 6.4/RHEL6 Update 4 -------------------> 2.6.32-358CentOS 6.5/RHEL6 Update 5 -------------------> 2.6.32-431CentOS 6.6/RHEL6 Update 6 -------------------> 2.6.32-504++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #后再分析下dump可以进crash模式了。

在linux下利用程序崩溃后的core文件分析bug(转载)

当我们的程序崩溃时，内核有可能把该程序当前内存映射到core文件里，方便程序员找到程序出现问题的地方。

最常出现的，几乎所有C程序员都出现过的错误就是“段错误”了。

也是最难查出问题原因的一个错误。

下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。

何谓core文件当一个程序崩溃时，在进程当前工作目录的core文件中复制了该进程的存储图像。

core文件仅仅是一个内存映象(同时加上调试信息)，主要是用来调试的。

当程序接收到以下UNIX信号会产生core文件：在系统默认动作列，“终止w/core”表示在进程当前工作目录的core文件中复制了该进程的存储图像（该文件名为core，由此可以看出这种功能很久之前就是UNIX功能的一部分）。

大多数UNIX 调试程序都使用core文件以检查进程在终止时的状态。

core文件的产生不是POSIX.1所属部分,而是很多UNIX版本的实现特征。

UNIX第6版没有检查条件(a)和(b)，并且其源代码中包含如下说明：“如果你正在找寻保护信号，那么当设置-用户-ID命令执行时，将可能产生大量的这种信号”。

4.3 + BSD产生名为core.prog的文件，其中prog是被执行的程序名的前1 6个字符。

它对core文件给予了某种标识，所以是一种改进特征。

表中“硬件故障”对应于实现定义的硬件故障。

这些名字中有很多取自UNIX早先在DP-11上的实现。

请查看你所使用的系统的手册，以确切地确定这些信号对应于哪些错误类型。

下面比较详细地说明这些信号。

? SIGABRT 调用abort函数时产生此信号。

进程异常终止。

? SIGBUS 指示一个实现定义的硬件故障。

? SIGEMT 指示一个实现定义的硬件故障。

EMT这一名字来自PDP-11的emulator trap 指令。

? SIGFPE 此信号表示一个算术运算异常，例如除以0，浮点溢出等。

? SIGILL 此信号指示进程已执行一条非法硬件指令。

Linux环境崩溃生成core文件以及调试

Linux环境崩溃⽣成core⽂件以及调试Windows环境崩溃问题可根据vs调试⼯具查看，Linux同样可以查看调⽤堆栈的信息，只是需要更改Linux设置，使程序崩溃时候产⽣core⽂件。

然后gdb调试即可。

1产⽣core⽂件⽅法当前会话的ulimit –c，若为0，则不会产⽣对应的coredump，需要进⾏修改和设置。

产⽣coredump的条件，⾸先需要确认当前会话ulimit -c unlimited (可以产⽣coredump且不受⼤⼩限制)，这种设置仅对当前⽣效，如果想永久⽣效那么需要在/etc/profile中加⼊以下⼀⾏，这将允许⽣成coredump⽂件ulimit-c unlimited2更改core dump⽣成路径因为core dump默认会⽣成在程序的⼯作⽬录，但是有些程序存在切换⽬录的情况，导致core dump⽣成的路径没有规律，所以最好是⾃⼰建⽴⼀个⽂件夹，存放⽣成的core⽂件。

我建⽴⼀个 /data/coredump ⽂件夹，在根⽬录data⾥的coredump⽂件夹。

调⽤如下命令echo /data/coredump/core.%e.%p> /proc/sys/kernel/core_pattern将更改core⽂件⽣成路径，⾃动放在这个/data/coredump⽂件夹⾥。

%e表⽰程序名， %p表⽰进程id3测试⽣成core⽂件以及调试该程序在core_test1()内部scanf的时候回崩溃，i前⾯应该加上&编译的时候带上-g选项，这样才能⽤gdb调试core运⾏后结果显⽰段错误进⼊/data/coredump⽂件夹可以查看⽣成的core⽤gdb调试该core，命令为 gdb core.ctest.6408 ,显⽰如下program terminated with signal 11 告诉我们信号中断了我们的程序敲命令： bt 可以打印堆栈信息这个⼀堆问号很多⼈遇到过，有⼈说是没加载符号表，有⼈说是标准glibc版本不⼀致，可以通过如下命令调试：gdb 可执⾏程序exe进⼊gdb环境后core-file core的名字敲命令bt可以查看准确信息。

故障排除 Linux操作系统死机处理方法总结

故障排除Linux操作系统死机处理方法总结通常在出现系统崩溃后，大家会担心再次出现故障，但是发现系统各日志中并没有记录到任何死机前后的信息，无法分析故障原因，认为已经无药可救。

但是，实际上，Linux 有多种机制来保证发生系统崩溃后，可以获取有价值的信息用以分析问题。

确定是硬件故障，还是应用程序bug 导致的。

Linux 中，有如下几种方法来获取各种崩溃时产生的信息。

1.Core dumpCore dump 通常用来调试应用程序错误，当某些应用程序运行出现异常崩溃时，可以开启系统的core dump 功能，来得到一个程序崩溃时的内存信息，用来分析崩溃原因：在/etc/profile里加上(或者修改)一条：ulimit -c 0运行命令：sysctl -w "kernel.core_name_format=/coredump/%n.core"该命令意思是指core文件放在/coredump目录下，文件名是进程名+.core2.Diskdumpdiskdump工具提供了在单机上创建和采集vmcore(kernel dump)的能力，而无须使用网络。

当内核本身出现崩溃的时候，当前的内存和CPU状态以及相关的信息都会被保存到一个支持diskdump的磁盘上的保留分区上。

在下一次重新启动的时候，当系统重新启动，diskdump的初始化脚本会从保留分区中读取保存的信息并创建一个vcore文件,然后这个文件被再次存放到/var/crash/目录下，文件名为127.0.0.1-如下是一个配置HP SCSI 设备上启用diskdump 的过程，如果不是HP SCSI 设备(即设备名为/dev/sdX的形式)，则无须执行第三、四两个步骤。

但需要在第一步前先执行命令：modprobediskdump第一步：编辑/etc/sysconfig/diskdump文件，将一个空白分区的设备名填入后保存退出，例如：DEVICE=/dev/cciss/c0d0p2第二步：初使化dump 设备#service diskdump initialformat警告：该分区的所以数据会丢失。

对象驱动的Linux内核crash分类技术研究

对象驱动的Linux内核crash分类技术研究对象驱动的Linux内核crash分类技术研究引言：Linux内核作为开源操作系统的核心，其稳定性和可靠性一直是广大用户和开发者关注的焦点。

然而，由于Linux内核的复杂性和多样性，当系统发生崩溃时，如何准确快速地定位问题并进行分类，成为了内核开发者必须面对的挑战。

本文将讨论对象驱动的Linux内核crash分类技术的研究，并探讨其在内核开发中的应用。

一、Linux内核crash分类技术的重要性Linux内核作为操作系统的核心，其崩溃将导致整个系统的不可用。

准确地识别问题的根本原因是保障系统稳定性的基础。

然而，由于内核的复杂性，一个崩溃可能涉及多个不同的模块和子系统，因此将内核crash进行分类能够更好地帮助开发者定位问题和采取相应的修复措施。

二、对象驱动的Linux内核crash分类技术的概述对象驱动的Linux内核crash分类技术是一种基于对象的分类方法。

其基本思想是将崩溃引起的中断、异常或错误视为对象，并根据这些对象的属性和行为进行分类。

通过建立对象的属性和行为的模型，可以更准确地识别内核crash的类型。

三、对象驱动的Linux内核crash分类技术的实现1. 对象模型的建立在对象驱动的Linux内核crash分类技术中，首先需要建立对象模型。

对象模型包括两个方面：属性和行为。

属性是指对象的静态特征，如类型、状态等；行为是指对象的动态特征，如触发崩溃的事件、与其他对象的交互等。

通过对对象模型进行建模，可以更好地描述崩溃的特征和原因。

2. 对象分类算法建立了对象模型后，需要设计有效的算法来进行对象分类。

对象分类算法主要包括以下几个步骤：首先，根据对象模型中的属性对所有对象进行初步分类；然后，通过分析对象的行为来细化分类结果；最后，根据分类结果找出崩溃的根本原因。

3. 实际案例分析为了验证对象驱动的Linux内核crash分类技术的实用性，我们选择了一个具体的案例进行分析。

kdump原理

kdump原理kdump是一个用于系统崩溃时自动采集内核转储(dump)信息的工具。

在Linu某系统中，当系统遇到严重故障导致崩溃时，会生成一个内核转储文件，也被称为"vmcore"或"crash dump"，用于分析故障原因。

kdump的原理是在系统崩溃时，将系统的转储信息保存到一个预定义的磁盘分区或者网络文件共享中，以便在系统重启后进行分析和调试。

1. 配置：在系统启动过程中，通过修改内核启动参数来指定kdump的配置信息。

主要设置包括转储保存的位置、转储文件名、触发转储的方式、转储前清理缓存的策略等。

2. 内存快照：当系统崩溃时，kdump首先捕获当前系统的内存快照。

这个过程称为"crash capture"。

kdump使用了一种特殊的机制，即通过在宕机过程中建立一个专用的内存分区，将内核和存储在内存中的关键信息复制到该分区中。

这个分区通常被称为"crashkernel"。

3. 内存复制：一旦内存快照被捕获，kdump会将这个快照的内容复制到指定的转储位置。

在复制过程中，kdump会排除一些不必要的信息，以减小转储文件的大小并提高分析效率。

4. 重启：在完成内存复制后，kdump会触发系统重启。

这个重启被称为"crash reboot"。

5. 分析：在系统重启后，可以使用特定的工具（如crash命令）来分析转储文件的内容，进一步了解崩溃原因。

分析可以包括查看进程状态、显示日志、检查系统资源和硬件状态等，以定位故障原因。

总结起来，kdump是Linu某系统中用于协助故障诊断和调试的一种工具，它通过在系统崩溃时自动采集内核转储信息并保存到指定位置，方便后续分析。

通过kdump，可以快速定位和解决系统崩溃的原因，提高系统的可靠性和稳定性。

linux崩溃有效排查方法

linux崩溃有效排查方法1. 查看系统日志：系统日志记录了系统的活动和错误信息。

你可以查看 `/var/log` 目录下的日志文件，如 `/var/log/syslog`、`/var/log/messages` 等，以获取关于崩溃的线索。

2. 使用 dmesg 命令：dmesg 命令用于显示内核环形缓冲区的消息。

它可以提供有关系统启动时的信息以及内核检测到的错误消息。

执行 `dmesg` 命令可以查看系统崩溃前的最后一些消息。

3. 分析崩溃转储文件：如果系统崩溃导致生成了崩溃转储文件（例如，`/var/crash/` 目录下的文件），你可以使用相关工具来分析这些文件，以确定崩溃的原因。

常用的工具包括 `gdb`、`mdb` 等。

4. 检查硬件问题：硬件故障也可能导致系统崩溃。

你可以检查硬件设备，如内存、硬盘、电源等是否正常工作。

可以使用硬件检测工具来进行诊断。

5. 查看进程状态：使用如 `top`、`ps` 等命令来查看系统当前的进程状态。

如果有异常的进程占用了大量资源或导致系统不稳定，可能是崩溃的原因之一。

6. 检查内核模块：某些内核模块的问题也可能导致系统崩溃。

你可以使用 `lsmod` 命令查看加载的内核模块，并检查是否有异常的模块。

7. 进行系统更新：确保你的 Linux 系统以及相关的软件包都是最新的版本。

有时更新可以修复已知的漏洞和问题。

8. 寻求专家帮助：如果你无法确定崩溃的原因或无法解决问题，可以寻求 Linux 专家或相关技术支持人员的帮助。

需要根据具体情况选择适当的排查方法。

在排查过程中，记录你所采取的步骤和结果，这有助于更快速地定位和解决问题。

linux主机利用crash分析_var_crash_下的vmcore 的dump分析

Linux系统进程崩溃日志分析脚本

Linux系统进程崩溃日志分析脚本尽管Linux系统一直以来都被认为是稳定可靠的操作系统，但是在某些情况下，进程崩溃仍然会发生。

当进程崩溃时，系统会生成相应的日志文件，这些日志文件包含了进程崩溃的详细信息。

为了更好地理解崩溃的原因以及采取相应的措施，我们可以编写一个Linux系统进程崩溃日志分析脚本。

脚本的主要目标是自动化分析日志文件，提取有用的信息，并将其呈现给管理员。

下面，我将介绍脚本的主要功能和使用步骤。

## 功能介绍1. 日志文件路径设置：脚本允许管理员通过指定日志文件的路径来进行分析。

这样的设置将在脚本的开头进行，在此之后，脚本将基于指定的路径来读取日志文件。

2. 进程崩溃信息提取：脚本将从日志文件中提取关键信息，包括崩溃原因、崩溃的时间和进程的相关信息。

脚本将使用字符串匹配和正则表达式来查找和提取这些信息。

3. 崩溃原因分类：脚本将根据崩溃原因对日志进行分类。

这将有助于管理员更好地理解崩溃的原因，并采取相应的措施。

4. 分析报告生成：脚本将生成分析报告，其中包括进程崩溃的统计信息和分类结果。

报告将以易读的方式呈现，并提供相应的建议和解决方案。

## 使用步骤1. 设置日志文件路径：在脚本的开头，管理员可以设置要分析的日志文件的路径。

确保指定的路径是正确的，以便脚本能够找到并读取日志文件。

2. 运行脚本：运行脚本时，它将读取指定路径下的日志文件，并自动进行分析。

脚本将显示进程崩溃的统计信息和分类结果。

3. 查看分析报告：脚本将生成一个分析报告文件，其中包含了进程崩溃的详细信息和建议。

管理员可以查看报告并根据需要采取相应的措施。

## 示例代码以下是一个简单的示例代码，展示了如何实现Linux系统进程崩溃日志分析脚本：```bash#!/bin/bash# 设置日志文件路径log_path="/var/log/syslog"# 提取崩溃信息crash_logs=$(grep -i "crash" $log_path)# 崩溃原因分类memory_crash=$(grep -i "out of memory" <<< $crash_logs)disk_crash=$(grep -i "disk I/O error" <<< $crash_logs)network_crash=$(grep -i "network failure" <<< $crash_logs)# 生成分析报告report_path="/tmp/crash_analysis_report.txt"echo "进程崩溃日志分析报告" > $report_pathecho "===================" >> $report_pathecho "崩溃统计信息：" >> $report_pathecho "---------------" >> $report_pathecho "总崩溃次数：$(wc -l <<< $crash_logs)" >> $report_path echo "内存崩溃次数：$(wc -l <<< $memory_crash)" >> $report_path echo "硬盘崩溃次数：$(wc -l <<< $disk_crash)" >> $report_path echo "网络崩溃次数：$(wc -l <<< $network_crash)" >> $report_path echo "" >> $report_pathecho "崩溃分类结果：" >> $report_pathecho "---------------" >> $report_pathecho "内存崩溃：$memory_crash" >> $report_pathecho "硬盘崩溃：$disk_crash" >> $report_pathecho "网络崩溃：$network_crash" >> $report_pathecho "分析报告已生成：$report_path"```以上示例代码只是一个简单的实现，实际的脚本可以根据需求进行更多的定制和改进。

crashkernel参数

crashkernel参数"crashkernel"参数通常用于Linux系统的内核启动参数中，它用于指定用于系统崩溃转储的内存大小和位置。

在Linux系统中，当系统遇到严重的错误导致崩溃时，内核会尝试将当前内存中的信息转储到预留的一块内存中，以便进行后续的分析和调试。

以下是关于"crashkernel"参数的详细解释：1. 内存大小，"crashkernel"参数中的值用于指定用于崩溃转储的内存大小。

这个值通常以MB为单位，例如"crashkernel=128M"表示预留128MB的内存用于崩溃转储。

根据系统的需求和内存大小，可以灵活地调整这个数值。

2. 内存位置，除了指定内存大小外，"crashkernel"参数还可以指定内存的位置。

例如，"crashkernel=256M@16M"表示预留256MB的内存，起始地址为物理内存的第16MB处。

这样的灵活性可以根据系统的实际情况进行调整。

3. 使用场景，"crashkernel"参数通常用于服务器环境或对系统稳定性要求较高的场景。

通过预留一部分内存用于崩溃转储，可以帮助系统管理员在系统崩溃时快速获取相关信息，有助于分析和解决问题。

4. 配置方法，在Linux系统中，可以通过boot loader（如GRUB）的配置文件（如grub.conf或grub.cfg）来设置"crashkernel"参数。

在这些配置文件中，可以添加类似"crashkernel=256M@16M"的参数来指定内存大小和位置。

总之，"crashkernel"参数在Linux系统中扮演着重要的角色，它为系统的稳定性和调试提供了重要的支持。

通过合理设置"crashkernel"参数，可以在系统崩溃时提供有效的调试信息，有助于加快故障排查和修复的速度。

crash rd命令的用法

crash rd命令的用法Crashrd命令是Linux系统中的一个非常有用的调试工具，它可以用来生成内核崩溃转储文件，并且可以在系统崩溃时自动执行。

在本文中，我们将介绍如何使用Crash rd命令来进行Linux系统的调试。

首先，我们需要安装Crash工具包，可以通过执行以下命令来进行安装：sudo apt-get install crash安装完成后，我们可以使用以下命令来生成内核崩溃转储文件： sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r)/var/crash/$(uname -n)-$(date +%Y%m%d-%H%M).dump在上面的命令中，/usr/lib/debug/boot/vmlinux-$(uname -r)表示内核映像文件的路径，/var/crash/$(uname -n)-$(date+%Y%m%d-%H%M).dump表示崩溃转储文件的路径和文件名。

执行该命令后，我们可以在指定的路径中找到生成的崩溃转储文件。

接下来，我们使用以下命令来打开Crash rd命令行界面：sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r)/var/crash/$(uname -n)-$(date +%Y%m%d-%H%M).dump在Crash rd命令行界面中，我们可以使用以下命令来进行调试： - bt：显示当前进程的函数调用栈。

- ps：显示当前系统中的所有进程。

- lsmod：显示当前系统中加载的所有模块。

- vm：显示当前系统中的虚拟内存布局。

- log：显示内核日志。

除了上述命令之外，还有许多其他的命令可以使用。

通过使用Crash rd命令，我们可以更加方便地进行Linux系统的调试和分析。

Linux宕机故障分析案例

Linux宕机故障分析案例Linux宕机故障分析案例马化辉背景在Linux系统环境下，服务器宕机发⽣的频率⽐较⼩，但是不少⼯程师或多或少都会遇到这种情况，有时候会⼿⾜⽆措，不知从何⼊⼿。

笔者将借助⼀次案例分析，展⽰下Linux宕机故障事件的处理⽅法和思路。

宕机发⽣的原因不⼀，或者是硬件原因，或者是性能原因，或者是服务器触发了Linux的bug，导致内核崩溃等等。

案例分析1、案情还原；⽣产系统服务器dcspodsaa1在4⽉25⽇凌晨00：49分发⽣服务器宕机故障，当时系统管理员对硬件报错进⾏了截图（保留现场很重要），看字⾯意思应该是服务器的swap设备发⽣损坏：2、分析⽅法⼀：使⽤sosreport收集系统⽇志，检查/var/log/messages⽇志，查找系统重启前是否存在错误⽇志，图中kernel***/proc/kmsg started代表系统启动的第⼀条⽇志，在此之前没有发现异常⽇志，3、分析⽅法⼆：检查服务器开启了kdump服务，并在/var/crash⽬录找到了当天⽣成的vmcore⽂件,使⽤crash⼯具分析vmcore⽂件，如下：服务器发⽣了严重的系统崩溃panic错误对kdmp⽂件的错误⽇志进⾏分析，发现了⼤量的swap 设备读写错误：5、分析⽅法三：检查系统历史性能记录，/var/log/sa/路径下记录了每天由sysstat服务收集的sar（system activity report）⽂件，默认每10分钟记录⼀次系统资源使⽤情况的信息，包括CPU、内存等。

通过sar命令查看系统宕机时负载情况，没有发现资源使⽤异常，基本可以排除不是系统因性能不⾜从⽽导致宕机4.25号性能记录⽂件使⽤命令sar –A –F sa25 | more检查CPU性能信息和内存性能信息，没有发现异常情况。

其他配置1. 开启kdump：安装依赖包启动服务设置开启启动修改默认crashkernel参数为256M, 注意需重启系统才⽣效2. 使⽤crash⼯具分析vmcore⽂件：1) 安装crash包，可使⽤yum安装2) 安装kernel-debug内核版本，该rpm包必需和故障系统的内核版本⼀致先使⽤unamre –r查看故障机版本安装相应包3) 启动crash检查⼩结因此，在处理故障时，⼀般的思路是：1. ⾸先应查找故障前的错误⽇志线索，可以通过检查系统messages⽇志中的错误⽇志；2. 如果没有，进⽽排查系统是否触发kdump服务（在系统由于内核崩溃⽽导致宕机时，可以捕获故障时内存中的故障信息）；3. 另外也需要分析系统资源（CPU、内存等）使⽤上出现异常。

Linux内核崩溃原因分析及错误跟踪技术

Linux内核崩溃原因分析及错误跟踪技术随着嵌入式Linux系统的广泛应用，对系统的可靠性提出了更高的要求，尤其是涉及到生命财产等重要领域，要求系统达到安全完整性等级3级以上[1]，故障率（每小时出现危险故障的可能性）为10-7以下，相当于系统的平均故障间隔时间（MTBF）至少要达到1141年以上，因此提高系统可靠性已成为一项艰巨的任务。

对某公司在工业领域14 878个控制器系统的应用调查表明，从2004年初到2007年9月底，随着硬软件的不断改进，根据错误报告统计的故障率已降低到2004年的五分之一以下，但查找错误的时间却增加到原来的3倍以上。

这种解决问题所需时间呈上升的趋势固然有软件问题，但缺乏必要的手段以辅助解决问题才是主要的原因。

通过对故障的统计跟踪发现，难以解决的软件错误和从发现到解决耗时较长的软件错误都集中在操作系统的核心部分，这其中又有很大比例集中在驱动程序部分[2]。

因此，错误跟踪技术被看成是提高系统安全完整性等级的一个重要措施[1]，大多数现代操作系统均为发展提供了操作系统内核“崩溃转储”机制，即在软件系统宕机时，将内存内容保存到磁盘[3]，或者通过网络发送到故障服务器[3]，或者直接启动内核调试器[4]等，以供事后分析改进。

基于Linux操作系统内核的崩溃转储机制近年来有以下几种：(1) LKCD（Linux Kernel Crash Dump）机制[3];(2) KDUMP（Linux Kernel Dump）机制[4]；(3) KDB机制[5]；(4) KGDB机制[6]。

综合上述几种机制可以发现,这四种机制之间有以下三个共同点：(1) 适用于为运算资源丰富、存储空间充足的应用场合；(2) 发生系统崩溃后恢复时间无严格要求；(3) 主要针对较通用的硬件平台，如X86平台。

在嵌入式应用场合想要直接使用上列机制中的某一种，却遇到以下三个难点无法解决：(1) 存储空间不足嵌入式系统一般采用Flash作为存储器，而Flash容量有限，且可能远远小于嵌入式系统中的内存容量。

linux crash的用法

linux crash的用法"Linux Crash"的用法引言：Linux是一种开源操作系统，它的稳定性和可靠性广受赞誉。

然而，就像任何其他操作系统一样，Linux也可能会出现崩溃的情况。

本文将详细探讨"Linux Crash"的用法，包括可能导致崩溃的因素以及如何应对和解决这些问题。

第一部分：Linux系统崩溃的原因1. 硬件故障：硬件故障是导致Linux系统崩溃的常见原因之一。

例如，内存故障、硬盘故障、电源问题等都可能导致系统无法正常运行。

2. 软件错误：软件错误也是Linux系统崩溃的常见原因之一。

例如，操作系统内核或其他关键软件的错误可能导致系统崩溃。

3. 驱动程序问题：Linux系统通常需要使用特定的驱动程序来与硬件设备进行交互。

不正确的驱动程序或驱动程序的冲突可能导致系统崩溃。

4. 内存管理问题：Linux系统使用虚拟内存管理机制来管理系统内存。

如果出现内存管理问题，例如内存泄漏或内存访问错误，系统可能会崩溃。

第二部分：应对Linux系统崩溃的步骤1. 重新启动系统：在系统崩溃后，第一步是尝试重新启动系统。

这可能是因为崩溃只是一个偶然事件，重新启动系统后问题可能会得到解决。

2. 分析错误日志：Linux系统通常会生成错误日志，记录系统崩溃时的相关信息。

通过分析错误日志，我们可以获得有关崩溃原因的线索，以便采取适当的措施。

- 使用命令"cat /var/log/syslog"来查看系统日志。

- 使用命令"dmesg"来查看内核日志。

3. 更新和修复软件：如果崩溃是由软件错误引起的，更新和修复软件可能是解决问题的方法之一。

通过使用包管理器来更新软件包，可以获得最新的错误修复和安全补丁。

- 在Debian或Ubuntu系统中，使用命令"apt-get update"和"apt-get upgrade"来更新软件包。

Linux内核Crash分析

Linux内核Crash分析在工作中经常会遇到一些内核crash的情况，本文就是根据内核出现crash后的打印信息，对其进行了分析，使用的内核版本为：Linux2.6.32。

每一个进程的生命周期内，其生命周期的范围为几毫秒到几个月。

一般都是和内核有交互，例如用户空间程序使用系统调用进入内核空间。

这时使用的不再是用户空间的栈空间，使用对应的内核栈空间。

对每一个进程来说，Linux内核都会把两个不同的数据结构紧凑的存放在一个单独为进程分配的存储空间中：一个是内核态的进程堆栈，另一个是紧挨进程描述符的数据结构thread_info,叫线程描述符。

内核的堆栈大小一般为8KB，也就是8192个字节，占用两个页。

在Linux-2.6.32内核中thread_info.h文件中有对内核堆栈的定义：1.#define THREAD_SIZE 8192在Linux内核中使用下面的联合结构体表示一个进程的线程描述符和内核栈，在内核中文件include/linux/sched.h。

1.union thread_union {2.struct thread_info thread_info;3.unsigned long stack[THREAD_SIZE/sizeof(long)];4.};该结构是一个联合体，我们在C语言书上看到过关于union的解释，在在C Programming Language 一书中对于联合体是这么描述的：1) 联合体是一个结构；2) 它的所有成员相对于基地址的偏移量都为0；3) 此结构空间要大到足够容纳最"宽"的成员；4) 其对齐方式要适合其中所有的成员；通过上面的描述可知，thread_union结构体的大小为8192个字节。

也就是stack数组的大小，类型是unsigned long类型。

由于联合体中的成员变量都是占用同一块内存区域，所以，在平时写代码时总有一个概念，对一个联合体的实例只能使用其中一个成员变量，否则会把原先变量给覆盖掉，这句话如果正确的话，必须要有一个前提假设，成员占用的字节数相同，当成员所占的字节数不同时，只会覆盖相应的字节。

crash分析vmcore

crash分析vmcore如何使⽤crash分析vmcore - 之基础思路case1dmesg查看内核⽇志[2493382.671020] systemd-shutdown[1]: Sending SIGKILL to PID 28975 (docker-containe).[2493382.671078] systemd-shutdown[1]: Sending SIGKILL to PID 29015 (systemd).[2493420.208723] EXT4-fs (nvme0n1p1): sb orphan head is140906170[2493420.209198] sb_info orphan list:[2493420.209663] inode nvme0n1p1:140906170 at ffff88490edabfb8: mode 100666, nlink 0, next 149423507[2493420.210129] inode nvme0n1p1:149423507 at ffff8801b99391a8: mode 100666, nlink 0, next 17567381[2493420.210583] inode nvme0n1p1:17567381 at ffff8806d4a26998: mode 100744, nlink 0, next 17570510[2493420.211050] inode nvme0n1p1:17570510 at ffff886387f82ef8: mode 100644, nlink 0, next 17570503[2493420.211508] inode nvme0n1p1:17570503 at ffff886a1f15bfb8: mode 100644, nlink 0, next 241700498[2493420.211966] inode nvme0n1p1:241700498 at ffff8877481800e8: mode 100644, nlink 0, next 243138756[2493420.212431] inode nvme0n1p1:243138756 at ffff88761ad10518: mode 100644, nlink 0, next 241565954[2493420.212900] inode nvme0n1p1:241565954 at ffff8870d64bbfb8: mode 100755, nlink 0, next 241566333[2493420.213366] inode nvme0n1p1:241566333 at ffff88721ae74c48: mode 100644, nlink 0, next 241050093[2493420.213833] inode nvme0n1p1:241050093 at ffff887704958948: mode 100755, nlink 0, next 241567324[2493420.214545] ------------[ cut here ]------------[2493420.219336] kernel BUG at fs/ext4/super.c:879! <<<======这⾥指明BUG的代码位置[2493420.223948] invalid opcode: 0000 [#1] SMP[2493420.228133] Modules linked in: kpatch_D751550(OE) kpatch_D631237(OE) unix_diag(E) af_packet_diag(E) netlink_diag(E) dccp_diag(E) dccp(E) tcp_diag(E) udp_diag(E) inet_diag(E) [last unloaded: aisqos_hotfixes] [2493420.246846] CPU: 58 PID: 1 Comm: systemd-shutdow Tainted: G W OE K 4.9.79-009.ali3000.alios7.x86_64 #1[2493420.257009] Hardware name: Inventec AliServer Thor01-2U /TB800G4-G1 , BIOS A1.2003/06/2018[2493420.267339] task: ffff887e45918000 task.stack: ffffc90000014000[2493420.273425] RIP: 0010:[<ffffffffa031a8df>] [<ffffffffa031a8df>] ext4_put_super+0x36f/0x3c0 [ext4] <<<=======这⾥指明BUG的代码位置[2493420.282593] RSP: 0018:ffffc90000017de8 EFLAGS: 00010206[2493420.288079] RAX: ffff88490edabf50 RBX: ffff887e43299000 RCX: 00000001949b336d[2493420.295384] RDX: 0000000000000000 RSI: 0000000000000206 RDI: 0000000000000206[2493420.302682] RBP: ffffc90000017e18 R08: 00000000000081a4 R09: 0000000000000000[2493420.309988] R10: 0000000000000cb8 R11: 0000000000001e92 R12: ffff887e43299278[2493420.317293] R13: ffff887e43298800 R14: ffff887e43299278 R15: ffffffffa034ff88[2493420.324598] FS: 00007f3241ccf840(0000) GS:ffff887e78480000(0000) knlGS:0000000000000000[2493420.332850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[2493420.338767] CR2: 00007f5e1372fbd0 CR3: 00000004daa52000 CR4: 00000000007606f0[2493420.346065] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[2493420.353361] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[2493420.360660] PKRU: 55555554[2493420.363536] Stack:[2493420.365721] 9cbae75a00000000 ffff887e43298800 ffffffffa034a5e0 ffff887e3818c7b8[2493420.373365] 0000000000000000 ffff887e45918bb0 ffffc90000017e38 ffffffff81244aaf[2493420.380991] 0000000000000083 ffff887e357b8680 ffffc90000017e58 ffffffff81244e37[2493420.388617] Call Trace:[2493420.391239] [<ffffffff81244aaf>] generic_shutdown_super+0x6f/0x100[2493420.397676] [<ffffffff81244e37>] kill_block_super+0x27/0x70[2493420.403508] [<ffffffff81244f73>] deactivate_locked_super+0x43/0x70[2493420.409945] [<ffffffff8124547a>] deactivate_super+0x5a/0x60[2493420.415770] [<ffffffff81264b2f>] cleanup_mnt+0x3f/0x90[2493420.421169] [<ffffffff81264bc2>] __cleanup_mnt+0x12/0x20[2493420.426733] [<ffffffff810a7b50>] task_work_run+0x80/0xa0[2493420.432306] [<ffffffff810032ba>] exit_to_usermode_loop+0xaa/0xb0[2493420.438572] [<ffffffff81003baa>] syscall_return_slowpath+0xaa/0xb0[2493420.445011] [<ffffffff8171a783>] entry_SYSCALL_64_fastpath+0xc3/0xc5[2493420.451623] Code: 6004000048 8b 80 e0 0000 <0f> 0b 49 c7 c7 88 ff 34 a0 49 8b[2493420.459829] RIP [<ffffffffa031a8df>] ext4_put_super+0x36f/0x3c0 [ext4][2493420.466633] RSP <ffffc90000017de8>crash>通过dmesg⽇志，我们可以通过两个⽅法判断 bug的代码位置：1. [2493420.219336] kernel BUG at fs/ext4/super.c:879!2. [2493420.273425] RIP: 0010:[<ffffffffa031a8df>] [<ffffffffa031a8df>] ext4_put_super+0x36f/0x3c0 [ext4]其中（0x36f代表和ext4_put_super函数⼊⼝的偏移量，0x3c0是基准地址）从2找到代码crash的具体位置：(gdb) p 0x36f$11 = 879反汇编函数，找到位置crash> dis -l ext4_put_super在crash中查看代码crash本⾝是可以查看代码的，前提是你需要加载模块，⽐如：加载模块ext4：crash> mod -s ext4crash> mod <<----列出所有的模块crash> l *ext4_put_super+0x36f0xffffffffa031a8df is in ext4_put_super (fs/ext4/super.c:879).874 * isn't empty. The on-disk one can be non-empty if we've875 * detected an error and taken the fs readonly, but the876 * in-memory list had better be clean by this point. */877if (!list_empty(&sbi->s_orphan))878 dump_orphan_list(sb, sbi);879 J_ASSERT(list_empty(&sbi->s_orphan));880881 sync_blockdev(sb->s_bdev);882 invalidate_bdev(sb->s_bdev);883if (sbi->journal_bdev && sbi->journal_bdev != sb->s_bdev) {只有当我们找到具体的代码，才能进⼀步分析代码，究竟为什么会crash，⽐如，这个函数的参数（可能是某个struct）的值到底是什么？bt打印栈bt栈[exception RIP: ext4_put_super+879]有可以看到是在函数ext4_put_super的第879⾏crash> btPID: 1 TASK: ffff887e45918000 CPU: 58 COMMAND: "systemd-shutdow"#0 [ffffc90000017a58] machine_kexec at ffffffff810603e8#1 [ffffc90000017ab8] __crash_kexec at ffffffff811211cd#2 [ffffc90000017b80] __crash_kexec at ffffffff811212a5#3 [ffffc90000017b98] crash_kexec at ffffffff811212eb#4 [ffffc90000017bb8] oops_end at ffffffff81030905#5 [ffffc90000017be0] die at ffffffff81030ddb#6 [ffffc90000017c10] do_trap at ffffffff8102df02#7 [ffffc90000017c60] do_error_trap at ffffffff8102e2d9#8 [ffffc90000017d20] do_invalid_op at ffffffff8102e830#9 [ffffc90000017d30] invalid_op at ffffffff8171b63e[exception RIP: ext4_put_super+879]RIP: ffffffffa031a8df RSP: ffffc90000017de8 RFLAGS: 00010206RAX: ffff88490edabf50 RBX: ffff887e43299000 RCX: 00000001949b336dRDX: 0000000000000000 RSI: 0000000000000206 RDI: 0000000000000206RBP: ffffc90000017e18 R8: 00000000000081a4 R9: 0000000000000000R10: 0000000000000cb8 R11: 0000000000001e92 R12: ffff887e43299278R13: ffff887e43298800 R14: ffff887e43299278 R15: ffffffffa034ff88ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018#10 [ffffc90000017de0] ext4_put_super at ffffffffa031a91c [ext4]#11 [ffffc90000017e20] generic_shutdown_super at ffffffff81244aaf#12 [ffffc90000017e40] kill_block_super at ffffffff81244e37#13 [ffffc90000017e60] deactivate_locked_super at ffffffff81244f73#14 [ffffc90000017e80] deactivate_super at ffffffff8124547a#15 [ffffc90000017e98] cleanup_mnt at ffffffff81264b2f#16 [ffffc90000017eb0] __cleanup_mnt at ffffffff81264bc2#17 [ffffc90000017ec0] task_work_run at ffffffff810a7b50#18 [ffffc90000017f00] exit_to_usermode_loop at ffffffff810032ba#19 [ffffc90000017f30] syscall_return_slowpath at ffffffff81003baa#20 [ffffc90000017f50] entry_SYSCALL_64_fastpath at ffffffff8171a783RIP: 00007f3241195c47 RSP: 00007fffb3db5438 RFLAGS: 00000246RAX: 0000000000000000 RBX: 0000560b87fbd920 RCX: 00007f3241195c47RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000560b87fbdd10RBP: 0000560b87fbda00 R8: 0000000000000000 R9: 00007f32410e416dR10: 0000000000000021 R11: 0000000000000246 R12: 0000560b87fbdd10R13: 00007fffb3db5538 R14: 00007fffb3db5523 R15: 0000000000000000ORIG_RAX: 00000000000000a6 CS: 0033 SS: 002bcrash>反汇编上下函数当我们，分析到了出错的具体的代码⾏，下⼀步需要分析，传⼊的参数和struct⾸先，我们需要看下函数ext4_put_super的原型，发现是static void ext4_put_super(struct super_block *sb),只有⼀个参数，⽽且是⼀个结构体struct super_block, 现在我们需要知道*sb指针的地址是多少呢？那这个地址肯定是上个函数generic_shutdown_super传递给它的.现在分析的关键是，我们需要知道,当generic_shutdown_super在ffffffff81244aaf处，调⽤到ext4_put_super的时候，传给ext4_put_super的指针地址是多少？⾸先，需要反汇编函数generic_shutdown_super找到地址ffffffff81244aafcrash> dis -l generic_shutdown_super/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/super.c: 4360xffffffff81244aa0 <generic_shutdown_super+96>: mov 0x30(%r12),%rax0xffffffff81244aa5 <generic_shutdown_super+101>: test %rax,%rax0xffffffff81244aa8 <generic_shutdown_super+104>: je 0xffffffff81244aaf <generic_shutdown_super+111>/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/super.c: 4370xffffffff81244aaa <generic_shutdown_super+106>: mov %rbx,%rdi <===rbx 和 rdi 数据⼀致0xffffffff81244aad <generic_shutdown_super+109>: callq *%rax <===在这⾥调⽤下个函数/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/include/linux/compiler.h: 2430xffffffff81244aaf <generic_shutdown_super+111>: mov 0x608(%rbx),%rax/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/super.c: 4390xffffffff81244ab6 <generic_shutdown_super+118>: lea 0x608(%rbx),%rdx0xffffffff81244abd <generic_shutdown_super+125>: cmp %rax,%rdx0xffffffff81244ac0 <generic_shutdown_super+128>: jne 0xffffffff81244b1f <generic_shutdown_super+223>接着，反汇编ext4_put_super, 你会发现push了很多的寄存器的值到stackcrash> dis -l ext4_put_super/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/ext4/super.c: 8240xffffffffa031a570 <ext4_put_super>: nopl 0x0(%rax,%rax,1) [FTRACE NOP]0xffffffffa031a575 <ext4_put_super+5>: push %rbp0xffffffffa031a576 <ext4_put_super+6>: mov %rsp,%rbp0xffffffffa031a579 <ext4_put_super+9>: push %r15 <===第1个寄存器⼊栈0xffffffffa031a57b <ext4_put_super+11>: push %r14 <===第2个寄存器⼊栈0xffffffffa031a57d <ext4_put_super+13>: push %r13 <===第3个寄存器⼊栈0xffffffffa031a57f <ext4_put_super+15>: push %r12 <===第4个寄存器⼊栈0xffffffffa031a581 <ext4_put_super+17>: mov %rdi,%r130xffffffffa031a584 <ext4_put_super+20>: push %rbx <===第5个寄存器⼊栈（rbx是在上个函数的时候，就有值的，所以，ext4_put_super函数的第⼀个参数的指针的地址就是这个寄存器的值）0xffffffffa031a585 <ext4_put_super+21>: sub $0x8,%rsp0xffffffffa031a589 <ext4_put_super+25>: mov 0x460(%rdi),%rbx/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/ext4/super.c: 8260xffffffffa031a590 <ext4_put_super+32>: mov 0xe0(%rbx),%r14/usr/src/debug/kernel-4.9.79-009.ali3000/linux-4.9.79-009.ali3000.alios7.x86_64/fs/ext4/super.c: 8300xffffffffa031a597 <ext4_put_super+39>: callq 0xffffffffa03133f0 <ext4_unregister_li_request>crash> bt -f#10 [ffffc90000017de0] ext4_put_super at ffffffffa031a91c [ext4]ffffc90000017de8: 9cbae75a00000000( ) ffff887e43298800(第5个寄存器的值)ffffc90000017df8: ffffffffa034a5e0(第4个寄存器的值) ffff887e3818c7b8(第3个寄存器的值)ffffc90000017e08: 0000000000000000(第2个寄存器的值) ffff887e45918bb0(第1个寄存器的值)ffffc90000017e18: ffffc90000017e38 ffffffff81244aaf(这两个是不代表寄存器的)#11 [ffffc90000017e20] generic_shutdown_super at ffffffff81244aafffffc90000017e28: 0000000000000083 ffff887e357b8680ffffc90000017e38: ffffc90000017e58 ffffffff81244e37crash> struct super_block ffff887e43298800struct super_block {s_list = {next = 0xffffffff81cb3db0 <super_blocks>, <=======这⾥也验证了，就是地址ffff887e43298800表⽰的就是struct super_block prev = 0xffff887e43968800},s_dev = 271581185,s_blocksize_bits = 12'\f',s_blocksize = 4096,s_maxbytes = 17592186040320,s_type = 0xffffffffa03589c0 <ext4_fs_type>,s_op = 0xffffffffa034a5e0 <ext4_sops>,dq_op = 0xffffffffa034a720 <ext4_quota_operations>,s_qcop = 0xffffffff81843f60 <dquot_quotactl_sysfile_ops>,s_export_op = 0xffffffffa034a580 <ext4_export_ops>,s_flags = 805371904,s_iflags = 1,s_magic = 61267,s_root = 0x0,s_umount = {count = {counter = -4294967295},wait_list = {next = 0xffff887e43298878,prev = 0xffff887e43298878},wait_lock = {raw_lock = {val = {counter = 0}}。

Linuxcrash工具

Linuxcrash工具什么是 crash如前文所述，当linux 系统内核发生崩溃的时候，可以通过kdump 等方式收集内核崩溃之前的内存，生成一个转储文件vmcore。

内核开发者通过分析该vmcore 文件就可以诊断出内核崩溃的原因，从而进行操作系统的代码改进。

那么crash 就是一个被广泛使用的内核崩溃转储文件分析工具，掌握crash 的使用技巧，对于定位问题有着十分重要的作用。

回页首使用 crash 的先决条件由于crash 用于调试内核崩溃的转储文件，因此使用crash 需要依赖如下条件：1. kernel 映像文件 vmlinux 在编译的时候必须指定了 -g 参数，即带有调试信息。

2. 需要有一个内存崩溃转储文件（例如vmcore），或者可以通过 /dev/mem 或/dev/crash 访问的实时系统内存。

如果 crash 命令行没有指定转储文件，则 crash 默认使用实时系统内存，这时需要 root 权限。

3. crash 支持的平台处理器包括：x86, x86_64, ia64, ppc64, arm, s390, s390x ( 也有部分 crash 版本支持 Alpha 和 32-bit PowerPC，但是对于这两种平台的支持不保证长期维护 )。

4. crash 支持 2.2.5-15（含）以后的 Linux 内核版本。

随着 Linux 内核的更新，crash 也在不断升级以适应新的内核。

回页首crash 安装指南要想使用crash 调试内核转储文件，需要安装crash 工具和内核调试信息包。

不同的发行版安装包名称略有差异，这里仅列出RHEL 和 SLES 发行版对应的安装包名称如下：表 1. crash 工具和内核调试包系统版本crash 工具名称内核调试信息包RHEL6.2 crash kernel-debuginfo-commonkernel-debuginfoSLES11SP2 crash kernel-default-debuginfokernel-ppc64-debuginfo以 RHEL 为例，安装 crash 及内核调试信息包的步骤如下：rpm -ivh crash-5.1.8-1.el6.ppc64.rpmrpm -ivh kernel-debuginfo-common-ppc64-2.6.32-220.el6.ppc64.rpmrpm -ivh kernel-debuginfo-2.6.32-220.el6.ppc64.rpm回页首启动 crash启动参数说明使用crash 调试转储文件，需要在命令行输入两个参数：debug kernel 和dump file，其中dump file 是内核转储文件的名称，debug kernel 是由内核调试信息包安装的，不同的发行版名称略有不同，以 RHEL 和 SLES 为例：RHEL6.2：/usr/lib/debug/lib/modules/2.6.32-220.el6.ppc64/vmlinuxSLES11SP2：/usr/lib/debug/boot/vmlinux-3.0.13-0.27-ppc64.debug使用 crash -h 或 man crash 可以查看 crash 支持的一系列选项，这里仅以常用的选项为例说明如下：-h：打印帮助信息-d：设置调试级别-S：使用 /boot/System.map 作为默认的映射文件-s：不显示版本、初始调试信息等，直接进入命令行-i file：启动之后自动运行 file 中的命令，再接受用户输入crash 报告分析crash 命令启动后，会产生一个转储文件的分析报告摘要，如下图所示。