红帽linux故障定位技术详解与实例

红帽linux故障定位技术详解与实例

ID:35432902

大小:74.80 KB

页数:14页

时间:2019-03-24

红帽linux故障定位技术详解与实例_第1页
红帽linux故障定位技术详解与实例_第2页
红帽linux故障定位技术详解与实例_第3页
红帽linux故障定位技术详解与实例_第4页
红帽linux故障定位技术详解与实例_第5页
资源描述:

《红帽linux故障定位技术详解与实例》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、红帽Linux故障定位技术详解与实例红帽Linux故障定位技术详解与实例是本文要介绍的内容,主要是来了解并学习红帽Linux中故障定位技术的学习,故障定位技术分为在线故障定位和离线故障定位,一起来看详解。1、故障定位(Debugging)场景分类为便于描述问题,将Linux上各种软件故障定位的情形分成两类:(1)在线故障故障定位在线故障定位(online-debugging)就是在故障发生时,故障所处的操作系统环境仍然可以访问,故障处理人员可通过console,ssh等方式登录到操作系统上,在shell上执行各种操作命令或测试程序的方式

2、对故障坏境进行观察,分析,测试,以定位出故障发生的原因。(2)离线故障定位离线故障定位(offline-debugging)就是在故障发牛时,故障所处的操作系统环境已经无法正常访问,但故障发生时系统的全部或部分状态已经被系统本身所固有或事先设定的方式收集起来,故障处理人员可通过对收集到的故障定位状态信息进行分析,定位出故障发生的原因。2、应用进程故障情形及处理应用进程的故障一般不会影响操作系统运行环境的止常使用(如果应用代码的bug导致了内核的crash或hang,则属于内核存在漏洞),所以可采用在线故障定位的方法,灵活的进行分析.应用

3、代码故障的情形有如下几种:(1)进程异常终止很多用户认为进程异常终止情况无从分析,但实际上进程异常终止情况都是有迹可寻的.所有的进程异常终止行为,都是通过内核发信号给特定进程或进程组实现的.可分成儿个类型进行描述:・SIGKILL.SIGKILL最特殊,因为该信号不可被捕获,同时SIGKILL不会导致被终止的进程产生core文件,但如果真正的是由内核中发出的SIGKILL,则内核一定会在dmesg中记录下信息.另外在内核中使用SIGKILL的地方屈指町数,如oom_kill_process()中,所以通过dmesg记录并且分析内核中使用

4、SIGKILL的代码,并不难分析原因-SIGQUIT,SIGILL,SIGABRT,SIGBUS,SIGFPE,SIGSEGVo这几个信号在保留情况下会终止进程并会产生core文件,用户根据core中的stacktrace信息,能直接定位出导致终止信号的代码位置。另外,SIGQUIT,S1GABRT-般是由用户代码自己使用的,好的代码一般会记录日志。SIGILL,SIGBUS,SIGFPE,SIGSEGV,都是由内核屮产生的,搜索内核源码,不难列出内核屮使用这几个信号的地方,如SIGILL是非法指令,可能是浮点运算产生的代码被corru

5、pted或文本区域的物理内存corruption;SIGBUS多由MCE故障定位导致:SIGSEGV多由应用代码的指针变量被corrupted导致。对于应用的heap或stack的内存被corrupted,可用valgrind工具对应用进行profile,通常能直接发现导致corruption的代码・SIGINT,SIGPIPE,SIGALRM,SIGTERM-这几个信号在保留情况下终止进程但不会产牛core文件。对这几个信号,建议用户一定要定义一个handler,以记录产生问题的上下文。比较容易忽略的是SIGPIPE,很多用户程序在使

6、用selectorpoll()时只监听read/write描述符,不监听exception描述符,在对方TCP己经关闭的情况下,仍然向socket中写入,导致SIGPIPE。・对于恶意的代吗产生的进程终止行为,如合作的一些进程屮,A向B发SIGKILL,而没做日志记录,或者B直接判断某条件而调用exit(),也没有做日志记录•在应用代码量很大的情况下,通过分析代码故障定位这种情形也许很难.SystemTap提供了解决这个问题的一个比较好的方法,就是写用八层的probes,追踪进程对signal(),exit()等系统调用的使用(1)进程

7、阻塞,应用无法正常推进这种情况,对于单个被阻寒的进程而言,属于正常状态,但对于包含多个进程的应用整体而言,属于异常。应用无法推进,说明其中某一个进程推进的因素出现了问题,导致其他依赖于它的进程也要等待.分析这种情形需要分析清楚进程或事件之间的依赖关系,及数据的处理流。首先要用gdb-p的backtrace功能查出各进程阻塞的执行路径,以确定每个进程所处在的状态机的位置。通常而言,如果只考虑各个进程的状态,则进程之间可能形成了一种互相依赖的环形关系,如(P1发请求=>P2处理=>P2发反应=>P1再请求=>P2处理=>P2再发反应),但应

8、用对workload,—般是按一个个的transaction或session的方式进行处理的,每个transaction都有起点和终点,我们需要用strace,tcpdump等工具以及应用的执行日志进行观察

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。