红帽Linux故障定位技术详解与实例.docx

红帽Linux故障定位技术详解与实例红帽javascript:;Linux故障定位技术详解与实例是本文要介绍的内容，主要是来了解并javascript:;学习红帽Linux中故障定位技术的学习，故障定位技术分为在线故障定位和离线故障定位，一起来看详解。　1、故障定位（Debugging）场景分类　为便于描述问题，将Linux上各种软件故障定位的情形分成两类：　（1）在线故障故障定位　在线故障定位（online-debugging）就是在故障发生时， 故障所处的javascript:;操作系统环境仍然可以访问，故障处理人员可通过console， ssh等方式登录到操作系统上，在javascript:;shell上执行各种操作命令或javascript:;测试程序的方式对故障环境进行观察，分析，测试，以定位出故障发生的原因。　（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一般是由用户代码自己使用的，好的代码一般会记录javascript:;日志。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）进程阻塞，应用无法正常推进　这种情况，对于单个被阻塞的进程而言，属于正常状态，但对于包含多个进程的应用整体而言，属于异常。应用无法推进，说明其中某一个进程推进的因素出现了问题，导致javascript:;其他依赖于它的进程也要等待. 分析这种情形需要分析清楚进程或事件之间的依赖关系，及数据的处理流。首先要用gdb -p 的back trace功能查出各进程阻塞的执行路径，以确定每个进程所处在的状态机的位置。　通常而言，如果只考虑各个进程的状态，则进程之间可能形成了一种互相依赖的环形关系，如（P1发请求=P2处理=P2发反应=P1再请求=P