下载文档原格式
Linux故障案例：从问题到解决在IT领域，Linux操作系统因其稳定性、安全性及开源性而受到广泛欢迎。
然而，即使是最好的系统也可能遇到问题。
以下是一个关于Linux故障的案例，以及如何解决这些问题的详细过程。
一、问题描述某公司服务器采用Red Hat Enterprise Linux (RHEL) 7.5操作系统。
最近，管理员发现服务器性能下降，应用程序响应缓慢。
此外，系统日志中存在大量与磁盘I/O相关的警告和错误信息。
二、问题分析首先，管理员检查系统资源使用情况，发现CPU和内存使用率均在正常范围内。
因此，问题可能出在磁盘I/O方面。
进一步分析系统日志，发现磁盘I/O问题的根源在于文件系统挂载选项“noauto”。
三、问题解决解决方案是将挂载选项“noauto”从文件系统挂载选项中移除。
管理员编辑了/etc/fstab文件，将涉及“noauto”选项的行注释掉或修改为正确的挂载选项。
保存文件后，管理员执行了以下命令重新挂载文件系统：四、问题验证重新挂载文件系统后，管理员检查系统性能和应用程序响应速度，发现一切恢复正常。
同时，系统日志中不再出现与磁盘I/O相关的警告和错误信息。
至此，问题得到圆满解决。
五、结论这个案例表明，对于Linux系统故障，仔细分析系统日志和资源使用情况是非常重要的。
在解决磁盘I/O问题时，管理员需要关注文件系统的挂载选项，特别是“noauto”选项的使用。
在编辑/etc/fstab文件时，务必小心谨慎，以免造成系统无法启动等严重后果。
通过适当的配置和调整，管理员可以确保Linux系统的稳定性和性能。
Linux命令行中的进程调试和错误排查技巧在Linux系统中，进程调试和错误排查是开发者和系统管理员必备的技能之一。
通过命令行界面，可以使用一系列工具和技巧来定位和解决进程中的错误和问题。
本文将介绍一些常用的Linux命令行中的进程调试和错误排查技巧，帮助读者快速定位和修复问题。
1. 进程的状态查看与管理在Linux系统中，可以通过以下命令查看和管理进程的状态：- `ps`：显示当前运行的进程列表。
可以使用`ps aux`命令查看所有进程的详细信息，包括PID（进程ID）、CPU使用率、内存占用等。
- `top`：实时动态显示进程列表和系统资源的使用情况。
按键盘上的`q`退出。
- `kill`：终止一个正在运行的进程。
使用`kill PID`命令，其中PID 是要终止的进程的ID。
- `killall`：终止指定进程名对应的所有进程。
使用`killallprocess_name`命令，其中process_name是要终止的进程名。
2. 进程的跟踪与调试当进程发生错误或异常时，可以使用以下命令进行跟踪和调试：- `strace`：跟踪系统调用和信号的发生情况。
使用`strace -p PID`命令，其中PID是要跟踪的进程ID。
- `gdb`：GNU调试器，可以对正在运行的进程进行调试。
使用`gdb -p PID`命令，其中PID是要调试的进程ID。
3. 日志分析与查看Linux系统中的日志文件记录了系统和各个进程的运行状态和错误信息。
以下是一些常用的日志文件和查看命令：- `/var/log/messages`：包含系统运行过程中的大量信息。
使用`tail -f /var/log/messages`命令实时查看该文件的最新内容。
- `/var/log/syslog`：包含系统日志信息，包括内核和其他系统组件的消息。
使用`tail -f /var/log/syslog`命令实时查看该文件的最新内容。
redhat操作系统故障分析与解决手册目录第一章Linux常用命令 (4)1.1常规查询命令 (4)1.1.1 查看修改主机IP地址命令 (4)1.1.2.查看主机网卡速率和全半双工设置 (5)1.1.3.查看修改主机路由表 (5)1.1.4.查看主机序列号 (6)1.1.5.查看操作系统发行版本和内核版本 (6)1.1.6.查看主机网卡&HBA卡 (6)1.1.7.查看主机系统盘和文件系统 (8)1.1.8.用户、组相关操作 (9)1.1.9.修改主机名 (9)1.1.10.网络链路聚合的设置 (9)第二章Linux系统检查 (10)2.1主机硬件检查 (10)2.2 操作系统关键日志检查 (11)2.3 操作系统性能检查 (11)2.3.1 主机当前整体负载情况 (11)2.3.2 CPU使用率 (13)2.3.2 内存使用率 (13)2.3.3 磁盘I/O (14)2.3.4 网卡流量 (14)2.3.5 当前主机端口监听情况 (15)第三章Linux参数调整 (16)5.1 ulimit参数调整 (16)5.1.1 修改主机最大进程数，最大文件打开数 (16)5.1.2 限制用户创建文件大小 (16)5.1.3 限制用户的管道缓冲区大小 (16)5.1.4 限制进程最大可用的虚拟内存 (16)5.2 修改系统内核参数 (16)第四章Linux故障处理 (17)6.1主机网络故障处理 (17)6.2 主机宕机故障 (18)6.3 HBA卡光纤链路故障 (18)第一章Linux常用命令1.1常规查询命令1.1.1 查看修改主机IP地址命令查看IP方法一：[root@ahdx-yqzl~]#ifconfig查看IP方法二：[root@ahdx-yqzl ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0修改主机IP[root@ahdx-yqzl ~]#vi /etc/sysconfig/network-scripts/ifcfg-eth0修改IPADDR，NETMASK，GATEWAY的值[root@ahdx-yqzl ~]#service network restart 重启network服务来使IP生效在一块网卡上生成多个IP[root@ahdx-yqzl ~]ifconfig eth0:1 134.64.101.98 netmks 255.255.255.224注：用ifconfig新增的IP保存在内存中，重启network或者重启主机以后，地址就失效了，如果长期使用建议采用新增网卡配置文件的方法在/etc/sysconfig/network-scripts目录里面创建一个名为ifcfg-eth0:1的文件内容样例为：DEVICE=eth0:1IPADDR=172.16.170.2BROADCAST=172.16.170.254 NETMASK=255.255.255.0ONBOOT=yes保存退出后，重启network后生效1.1.2.查看主机网卡速率和全半双工设置[root@ahdx-yqzl ~]# ethtool eth01.1.3.查看修改主机路由表查看路由表方法一：[root@ahdx-yqzl ~]# netstat -rn查看路由表方法二：[root@ahdx-yqzl ~]# route –n增加路由：增加某一个IP的路由route add -host 192.168.198.34 gw 172.29.97.1 dev eth0增加某一段IP路由route add -host 192.168.198.0 netmask 255.255.255.0 gw 172.29.97.1 dev eth0删除某一条路由route del –host 192.168.198.341.1.4.查看主机序列号[root@ahdx-yqzl ~]# dmidecode -s system-serial-number注：在某些刀片机安装的Redhat需要使用下面的命令查看序列号[root@ahdx-yqzl ~]#dmidecode -s chassis-serial-number1.1.5.查看操作系统发行版本和内核版本查看操作系统发行版本方法一：[root@ahdx-yqzl ~]# head -n 1 /etc/issue查看操作系统发行版本方法二：注：在一些主机上安装oracle时会修改/etc/redhat-release中的发行版本号，所以有时候用方法二看到的操作系统发行版本并不一定是真实的。
linux故障排查案例【原创实用版】目录1.案例一：Linux 系统无法启动2.案例二：系统崩溃后无法进入图形界面3.案例三：网络连接故障4.案例四：磁盘空间不足5.案例五：系统安全漏洞正文在 Linux 操作系统中，有时会出现各种故障，影响用户的正常使用。
下面我们将通过几个具体的案例，介绍如何进行 Linux 故障排查。
案例一：Linux 系统无法启动当 Linux 系统无法正常启动时，我们可以通过以下步骤进行排查：1.检查硬件设备是否正常，如内存、硬盘等。
2.尝试进入 GRUB 引导菜单，查看是否有可用的系统版本。
3.使用 LILO 或 GRUB 等引导管理器进行系统引导。
4.若以上方法都无法解决问题，可尝试使用 Linux Live CD 或 USB 设备进行系统修复。
案例二：系统崩溃后无法进入图形界面如果 Linux 系统在崩溃后无法进入图形界面，可以尝试以下方法：1.通过 Ctrl + Alt + F3 进入命令行模式。
2.登录后，运行“startx”命令启动图形界面。
3.若无法启动图形界面，尝试重新安装显卡驱动。
4.若问题仍未解决，可尝试重新安装桌面环境。
案例三：网络连接故障当 Linux 系统出现网络连接故障时，可以采取以下措施：1.查看网络配置文件，确认网络接口配置是否正确。
2.尝试重启网络服务，如重启“network”或“net.ipv4”服务。
3.若网络连接仍然有问题，可尝试使用网络诊断工具，如“ping”或“traceroute”检查网络连通性。
4.若问题仍未解决，可尝试检查物理网线连接及路由器设置。
案例四：磁盘空间不足当 Linux 系统磁盘空间不足时，可以采取以下措施：1.查看磁盘使用情况，确认哪些目录占用空间较大。
2.删除无用的文件和目录，释放磁盘空间。
3.对日志文件进行清理，以减少磁盘占用。
4.若磁盘空间仍然不足，可考虑对系统进行磁盘分区调整，增加磁盘空间。
案例五：系统安全漏洞针对 Linux 系统的安全漏洞，我们可以采取以下措施：1.及时更新系统内核、软件包和桌面环境，修复已知的安全漏洞。
Linux操作系统中的故障检测与恢复Linux操作系统是一种自由开放源码的操作系统，广泛应用于各个领域。
在长期的使用中，难免会遇到一些故障和问题。
本文将探讨Linux操作系统中的故障检测与恢复方法，帮助读者更好地理解和解决这些问题。
一、故障检测1.1 系统日志的分析Linux操作系统记录了大量的系统日志，包含了操作系统运行过程中的各种信息，如启动、关闭、错误等。
我们可以通过查看系统日志来分析和定位故障。
在终端中使用命令`cat /var/log/syslog`可以查看系统日志文件内容。
如果需要筛选特定关键词，可以使用`grep`命令进行过滤，例如`grep "error" /var/log/syslog`。
1.2 使用命令行工具Linux操作系统提供了一系列的命令行工具，用于诊断和检测系统故障。
以下是一些常用的命令行工具：- `top`：用于查看系统进程的运行情况，包括占用CPU、内存等资源的情况。
- `iotop`：用于监控磁盘I/O的情况，可以查看哪些进程在进行磁盘读写操作。
- `netstat`：用于查看网络连接情况，包括监听的端口、连接状态等。
- `ps`：用于查看系统进程的详细信息，包括进程ID、父进程ID、内存使用情况等。
这些命令行工具可以帮助我们深入了解系统的当前状态，从而快速诊断故障。
1.3 进程状态监控通过监控系统中运行的进程状态，可以及时发现并解决潜在的问题。
常见的进程状态监控工具有`Monit`、`Munin`、`Nagios`等。
这些工具可以实时监控进程的运行状态、资源占用情况等，并在发现异常时发送警报。
二、故障恢复2.1 备份与还原在Linux操作系统中，没有备份就没有安全。
备份是故障恢复的重要手段之一。
可以使用`tar`命令创建文件和目录的备份，例如`tar -cvf backup.tar/path/to/directory`。
还原备份可以使用`tar -xvf backup.tar`命令。
Linux系统故障排查与修复在使用Linux系统的过程中，难免会遇到各种故障和问题。
正确地进行系统故障排查与修复是确保系统稳定性和可靠性的重要步骤。
本文将详细介绍Linux系统故障排查与修复的方法和步骤，帮助读者解决常见的故障和问题。
一、故障排查前的准备工作在进行故障排查之前，有一些准备工作是必不可少的。
首先，我们需要了解系统的基本信息，包括操作系统版本、硬件配置和网络环境等。
其次，我们需要备份重要的数据和配置文件，以防止在排查故障的过程中数据丢失或配置被修改。
最后，我们需要准备一些常用的故障排查工具，如ping、netstat、top等，以便在需要时进行分析和排查。
二、故障排查步骤1. 观察和记录当系统出现故障时，首先需要观察和记录故障的现象、出现的时间和频率等信息。
这些信息有助于后续的故障分析和判断。
2. 确定故障的范围在排查故障之前，我们需要确定故障的范围，是整个系统的故障还是某个特定的组件或服务的故障。
这有助于我们缩小故障排查的范围，提高效率。
3. 检查系统日志系统日志是排查故障的重要信息来源。
通过查看系统日志，我们可以了解系统在故障发生时的状态和报错信息，从而找到故障的原因。
4. 检查网络连接如果故障与网络连接相关，我们需要检查网络连接是否正常。
可以通过使用ping命令测试网络连通性，使用netstat命令查看网络连接状态等。
5. 检查硬件设备如果故障可能与硬件设备相关，我们需要检查硬件设备是否正常工作。
可以查看硬件设备的状态和日志，检查硬件设备的连接和供电等。
6. 检查系统资源如果系统资源不足可能导致系统故障，可以使用top命令查看系统的资源使用情况，如CPU、内存和磁盘等。
如果发现某个资源占用过高，可能需要对其进行优化或增加相应的资源。
7. 分析和解决故障通过以上步骤的检查和分析，我们应该能够确定故障的原因或者一些可能的原因。
根据故障的原因，选择相应的解决方法进行修复。
三、常见故障和解决方法1. 网络故障网络故障是使用Linux系统时常见的问题之一。
红帽Linux故障定位技术详解与实例红帽Linux故障定位技术详解与实例是本文要介绍的内容，主要是来了解并学习红帽Linux中故障定位技术的学习，故障定位技术分为在线故障定位和离线故障定位，一起来看详解。
1、故障定位（Debugging）场景分类为便于描述问题，将Linux上各种软件故障定位的情形分成两类：（1）在线故障故障定位在线故障定位（online-debugging）就是在故障发生时，故障所处的操作系统环境仍然可以访问，故障处理人员可通过console，ssh等方式登录到操作系统上，在shell上执行各种操作命令或测试程序的方式对故障环境进行观察，分析，测试，以定位出故障发生的原因。
（2）离线故障定位离线故障定位（offline-debugging）就是在故障发生时，故障所处的操作系统环境已经无法正常访问，但故障发生时系统的全部或部分状态已经被系统本身所固有或事先设定的方式收集起来，故障处理人员可通过对收集到的故障定位状态信息进行分析，定位出故障发生的原因。
2、应用进程故障情形及处理应用进程的故障一般不会影响操作系统运行环境的正常使用（如果应用代码的bug导致了内核的crash或hang，则属于内核存在漏洞），所以可采用在线故障定位的方法，灵活的进行分析. 应用代码故障的情形有如下几种：（1）进程异常终止很多用户认为进程异常终止情况无从分析，但实际上进程异常终止情况都是有迹可寻的. 所有的进程异常终止行为，都是通过内核发信号给特定进程或进程组实现的. 可分成几个类型进行描述：- SIGKILL. SIGKILL最特殊，因为该信号不可被捕获，同时SIGKILL不会导致被终止的进程产生core文件，但如果真正的是由内核中发出的SIGKILL，则内核一定会在dmesg中记录下信息. 另外在内核中使用SIGKILL的地方屈指可数，如oom_kill_process()中，所以通过dmesg记录并且分析内核中使用SIGKILL的代码，并不难分析原因- SIGQUIT，SIGILL，SIGABRT，SIGBUS，SIGFPE，SIGSEGV。
linux运维故障案例在Linux运维工作中，故障案例是经常会遇到的。
本文将结合实际案例，介绍几种常见的Linux运维故障，并给出解决方法。
1. 硬件故障。
在Linux运维过程中，硬件故障是比较常见的问题之一。
例如，服务器突然宕机，无法启动，或者硬盘损坏等。
针对这种情况，首先要检查硬件是否连接正常，排除硬件故障。
其次，可以通过硬件诊断工具来检测硬件是否损坏，如果是硬盘故障，可以尝试使用备用硬盘进行替换。
另外，定期做好硬件的维护和检测也是预防硬件故障的重要手段。
2. 网络故障。
网络故障是影响服务器正常运行的重要因素之一。
比如，服务器无法访问外网，或者内网之间无法通信等。
针对这种情况，可以先检查网络设备是否正常工作，比如路由器、交换机等。
其次，可以使用ping命令来测试网络连通性，查找网络故障的具体位置。
另外，及时更新网络设备的驱动程序和固件，也是预防网络故障的有效措施。
3. 系统故障。
系统故障是Linux运维中比较常见的问题，比如操作系统崩溃、内核错误等。
针对这种情况，可以使用系统日志来查找故障原因，比如/var/log/messages和/var/log/syslog等。
另外，及时安装系统更新和补丁，加强系统安全性，也是预防系统故障的重要手段。
4. 软件故障。
在Linux运维中，软件故障也是比较常见的问题，比如应用程序崩溃、数据库无法启动等。
针对这种情况，可以通过查看应用程序日志来定位故障原因，比如/var/log/nginx/error.log和/var/log/mysql/error.log等。
另外，定期备份重要数据和配置文件，也是预防软件故障的有效手段。
总之，Linux运维故障案例是我们在工作中经常会遇到的问题，针对不同的故障情况，我们需要灵活运用各种工具和方法来解决。
同时，做好预防工作，定期检测和维护系统，可以有效降低故障发生的概率，保障系统的稳定运行。
Linux系统故障排查与故障单管理Linux系统是许多企业和个人选择的首选操作系统之一，但在使用过程中难免会遇到各种故障。
本文将详细介绍Linux系统故障排查的步骤和故障单的管理方法，帮助读者快速解决问题并提高系统的稳定性和可靠性。
一、故障排查步骤1. 收集信息故障排查的第一步是收集与故障相关的信息，包括系统日志、错误信息、应用程序输出等。
通过这些信息可以初步了解故障发生的原因和过程。
2. 检查硬件硬件故障是导致系统故障的一个常见原因。
检查硬件设备是否正常连接、供电是否稳定、硬盘是否工作正常等。
如果有可能，可以尝试更换硬件设备或连接线缆，以确认是否是硬件故障导致的问题。
3. 检查网络连接网络连接问题也是Linux系统故障的常见原因之一。
检查网络连接是否正常，包括网络线缆、路由器、防火墙等设备的状态。
可以使用网络诊断工具如ping、traceroute等进行网络连接测试。
4. 分析软件配置配置错误是导致系统故障的常见原因之一。
检查相关软件的配置文件，确认配置是否正确。
可以对比备份文件或参考官方文档来参照正确的配置。
5. 检查运行状态通过查看相关进程和服务的运行状态，确定是否有服务未启动、进程挂起等情况。
可以使用命令如ps、top等来查看进程的状态和资源使用情况。
6. 分析日志文件系统日志是排查Linux系统故障的重要依据。
通过查看系统日志文件，查找异常信息并定位故障的原因。
常见的系统日志文件包括/var/log/messages、/var/log/syslog等。
二、故障单管理方法在解决Linux系统故障过程中，及时记录和管理故障单是非常重要的。
故障单可以帮助快速回顾故障处理过程和成败经验，并能为未来的故障排查提供参考。
以下介绍几个故障单管理的方法：1. 故障描述在填写故障单时，首先要准确描述故障现象，包括故障发生的时间、出现的具体问题以及对系统产生的影响。
这样可以让接手故障单的人快速了解问题的背景。
linux系统故障及解决方法Linux系统故障及解决方法Linux系统是一种开源的操作系统，由于其稳定性和安全性，越来越多的企业和个人选择使用它。
但是，就像其他操作系统一样，Linux系统也会出现故障。
本文将按照故障的类别，介绍Linux系统故障的解决方法。
一、系统启动故障1.1 问题描述当您尝试启动Linux系统时，可能会遇到以下问题：- 系统无法启动，只显示黑屏。
- 系统启动后，出现错误信息。
- 系统启动后，无法进入桌面环境。
1.2 解决方法- 检查硬件：检查硬盘、内存、显卡等硬件是否正常。
- 检查启动项：检查启动项是否正确，是否存在错误。
- 恢复系统：使用Live CD或USB启动系统，进入恢复模式，修复系统文件。
二、网络故障2.1 问题描述当您尝试连接网络时，可能会遇到以下问题：- 无法连接网络。
- 网络连接速度慢。
- 网络连接不稳定。
2.2 解决方法- 检查网络设置：检查网络设置是否正确，包括IP地址、网关、DNS 等。
- 检查网络硬件：检查网络硬件是否正常，包括网卡、路由器等。
- 检查网络服务：检查网络服务是否正常运行，包括DHCP、DNS等。
三、软件故障3.1 问题描述当您尝试运行软件时，可能会遇到以下问题：- 软件无法启动。
- 软件运行缓慢。
- 软件崩溃或出现错误信息。
3.2 解决方法- 检查软件依赖：检查软件依赖是否满足，包括库文件、运行环境等。
- 检查软件配置：检查软件配置是否正确，包括配置文件、权限等。
- 重新安装软件：如果软件出现严重问题，可以尝试重新安装软件。
四、安全故障4.1 问题描述当您尝试保护系统安全时，可能会遇到以下问题：- 系统遭受黑客攻击。
- 系统感染病毒或恶意软件。
- 系统出现安全漏洞。
4.2 解决方法- 更新系统：及时更新系统补丁，修复安全漏洞。
- 安装杀毒软件：安装杀毒软件，定期扫描系统。
- 配置防火墙：配置防火墙，限制网络访问。
总结Linux系统故障的解决方法需要根据具体情况而定，但是，无论是哪种故障，都需要及时处理，以保证系统的稳定性和安全性。
红帽Linux故障定位技术详解与实例红帽Linux故障定位技术详解与实例是本文要介绍的内容，主要是来了解并学习红帽Linux中故障定位技术的学习，故障定位技术分为在线故障定位和离线故障定位，一起来看详解。
1、故障定位（Debugging）场景分类为便于描述问题，将Linux上各种软件故障定位的情形分成两类：（1）在线故障故障定位在线故障定位（online-debugging）就是在故障发生时，故障所处的操作系统环境仍然可以访问，故障处理人员可通过console，ssh等方式登录到操作系统上，在shell上执行各种操作命令或测试程序的方式对故障环境进行观察，分析，测试，以定位出故障发生的原因。
（2）离线故障定位离线故障定位（offline-debugging）就是在故障发生时，故障所处的操作系统环境已经无法正常访问，但故障发生时系统的全部或部分状态已经被系统本身所固有或事先设定的方式收集起来，故障处理人员可通过对收集到的故障定位状态信息进行分析，定位出故障发生的原因。
2、应用进程故障情形及处理应用进程的故障一般不会影响操作系统运行环境的正常使用（如果应用代码的bug导致了内核的crash或hang，则属于内核存在漏洞），所以可采用在线故障定位的方法，灵活的进行分析. 应用代码故障的情形有如下几种：（1）进程异常终止很多用户认为进程异常终止情况无从分析，但实际上进程异常终止情况都是有迹可寻的. 所有的进程异常终止行为，都是通过内核发信号给特定进程或进程组实现的. 可分成几个类型进行描述：- SIGKILL. SIGKILL最特殊，因为该信号不可被捕获，同时SIGKILL不会导致被终止的进程产生core文件，但如果真正的是由内核中发出的SIGKILL，则内核一定会在dmesg中记录下信息. 另外在内核中使用SIGKILL的地方屈指可数，如oom_kill_process()中，所以通过dmesg记录并且分析内核中使用SIGKILL的代码，并不难分析原因- SIGQUIT，SIGILL，SIGABRT，SIGBUS，SIGFPE，SIGSEGV。
这几个信号在保留情况下会终止进程并会产生core文件，用户根据core中的stack trace信息，能直接定位出导致终止信号的代码位置。
另外，SIGQUIT，SIGABRT一般是由用户代码自己使用的，好的代码一般会记录日志。
SIGILL，SIGBUS，SIGFPE，SIGSEGV，都是由内核中产生的，搜索内核源码，不难列出内核中使用这几个信号的地方，如SIGILL 是非法指令，可能是浮点运算产生的代码被corrupted或文本区域的物理内存corruption；SIGBUS多由MCE故障定位导致；SIGSEGV 多由应用代码的指针变量被corrupted导致。
对于应用的heap或stack的内存被corrupted，可用valgrind工具对应用进行profile，通常能直接发现导致corruption的代码- SIGINT，SIGPIPE，SIGALRM，SIGTERM。
这几个信号在保留情况下终止进程但不会产生core文件。
对这几个信号，建议用户一定要定义一个handler，以记录产生问题的上下文。
比较容易忽略的是SIGPIPE，很多用户程序在使用select()或poll()时只监听read/write描述符，不监听exception描述符，在对方TCP已经关闭的情况下，仍然向socket中写入，导致SIGPIPE。
- 对于恶意的代吗产生的进程终止行为，如合作的一些进程中，A向B发SIGKILL，而没做日志记录，或者B直接判断某条件而调用exit()，也没有做日志记录.在应用代码量很大的情况下，通过分析代码故障定位这种情形也许很难. SystemTap提供了解决这个问题的一个比较好的方法，就是写用户层的probes，追踪进程对signal()，exit()等系统调用的使用（2）进程阻塞，应用无法正常推进这种情况，对于单个被阻塞的进程而言，属于正常状态，但对于包含多个进程的应用整体而言，属于异常。
应用无法推进，说明其中某一个进程推进的因素出现了问题，导致其他依赖于它的进程也要等待. 分析这种情形需要分析清楚进程或事件之间的依赖关系，及数据的处理流。
首先要用gdb -p 的back trace功能查出各进程阻塞的执行路径，以确定每个进程所处在的状态机的位置。
通常而言，如果只考虑各个进程的状态，则进程之间可能形成了一种互相依赖的环形关系，如（P1发请求=>P2处理=>P2发反应=>P1再请求=>P2处理=>P2再发反应），但应用对workload，一般是按一个个的transaction 或session的方式进行处理的，每个transaction都有起点和终点，我们需要用strace，tcpdump 等工具以及应用的执行日志进行观察，分析出当前正被处理的transaction所被阻滞的位置，从而找出全部状态机被阻塞的原因。
导致这种状态机停止运转的原因有多个：如和应用通信的远端出现了问题，后端数据库/目录等出现了问题，应用的某个进程或线程处于非正常的blocking位置或直接终止，不再正常工作。
（3）用户进程形成死锁用户进程形成死锁，如果没有内存上的故障定位，则完全是应用自身的逻辑问题。
死锁的进程或线程之间由于锁的互相占有形成了环路。
这种情况发生时，用gdb -p 的back trace的功能能直接确定死锁的进程全部阻塞在futex()等和锁相关的系统调用上，这些调用futex()的路径可能是mutex，semaphore，conditional variable 等锁函数。
通过分析call trace 的代码，能直接确定各进程在执行到该位置时，可能已经持有的全部锁，根据这个修改程序的代码，消除死锁环路，就可解决问题。
注意，内存故障也可导致假的死锁的，如物理内存故障可直接导致锁变量的值为-1，所以使用该锁的进程都会阻塞. 如果是代码的bug导致的内存corruption，可用valgrind工具检查程序来发现。
但如果是物理内存的故障定位导致的corruption，则需要硬件的支持，对于高端的PC，如MCE功能的机器，当物理内存故障定位时能直接产生异常或报告，但对于低端PC服务器，除了运行memtest工具进行检测外，没有其他方法。
（4）进程长期处于'D' （UnInterruptible）状态没法退出这种多是由内核中的故障引起的。
内核在很多执行路径中会将进程至于'D'的状态，以确保关键的执行路径不被外部的信号中断，导致不必要的内核中数据结构状态的不一致性。
但一般而言，进程处于'D' 状态的时间不会太久，因为状态结束的条件（如timer触发，IO操作完成等）很快会将进程唤醒. 当进程长期处于'D'，关键是要找出其阻塞的代码位置，用sysrq 的t键功能可直接打印出系统中全部睡眠进程的内核执行堆栈，如echo 't' > /proc/sysrq-trigger，其中包括出现'D'状态的进程的内核态堆栈。
找出代码位置后，一般可直接分析出'D' 状态不能退出的原因，如IO read操作因硬件或nfs故障而不能完成。
有可能导致'D' 状态的原因比较复杂，如…D‟的退出依赖于某变量的值，而该变量的值因某种原因被永久corrupted掉了。
3、内核故障情形及处理（1）内核panicpanic是内核最直接的故障定位报告，发生panic时，内核已经认为故障定位已经导致操作系统不再具备正常运行的条件了。
当发生panic时，Linux会将所有CPU的中断和进程调度功能都关掉，所以这时系统是没有任何反应的，如果用户启动的是图形界面，则在屏幕上也看不到任何关于panic的信息。
我们通常遇到的，机器没反应，ping不通的情况，绝大部分都是panic。
Panic发生时，内核直接在console上打印导致panic的代码位置的调用堆栈，传统的用户用串口连接到机器上来收集console上的打印信息，但串口这种方式，显然用起来不方便，现在的Linux，如RHEL5，RHEL6，都采用kdump的方法来收集panic时的信息。
在配置好kdump的情况下，panic时系统会用kexec加载并切换到一个新的内核上（放置在预先分配的内存位置），并用磁盘或网络等将系统的全部或部分内存数据保存起来。
用kdump收集到panic的数据后，用户用crash工具就能直接查看导致panic的代码路径。
panic一般是很直观的，panic的堆栈信息能直接反映出导致bug的原因，如MCE故障，NMI故障，数据结构分配失败等。
但有时panic是因为内核主动发现了关键的数据结构不一致性，这种不一致性是什么时候，什么代码导致的，并不清楚，可能还需要多次测试用SystemTap这样的工具进行捕捉（2）多处理机环境内核执行路径产生的死锁内核死锁和panic不一样，产生死锁时，内核并不主动的使自己处于挂起状态。
但内核死锁发生时，两个以上的CPU的执行路径在内核态不能推进了，处于互相阻塞状态，而且是100%的占用CPU（用的spin-lock），直接或间接的导致全部CPU上的进程无法调度。
内核死锁又分两种情况：- 涉及到中断上下文的死锁。
这种情况的死锁，最少一个CPU上的中断被屏蔽了。
系统可能没法响应ping请求。
由于有一个CPU已经没法响应中断，其上的local APIC定时中断没法工作，可以用NMI Watchdog的方法来检测出来（检查local APIC handler维护的计数器变量），NMI Watchdog可以在其处理程序中调用panic（），用户就可以用kdump收集内存信息，从而分析各死锁CPU上的调用堆栈，查处导致死锁的逻辑原因。
- 不涉及中断上下文的死锁。
这种情况的死锁，各CPU上的中断都是正常的，系统能对ping请求作出反应，这时NMI Watchdog无法被触发。
在2。
6。
16之前的内核中，并没有一种很好的方法来处理这种情形。
在RHEL5，RHEL6 内核中，每个CPU上提供了一个watchdog内核线程，在死锁出现的情况下，死锁CPU上的watchdog内核线程没法被调度（即使它是最高优先级的实时进程），它就没法update相应的counter变量，各CPU的NMI Watchdog 中断会周期性的检查其CPU对应的counter，发现没有updated，会调用panic（），用户就可用kdump收集内存信息，分析各死锁CPU上的调用堆栈，查处导致死锁的逻辑原因。
