网站设计的专业流程,网络营销推广的研究方向,内蒙住房和城乡建设部网站首页,微信订阅号网站开发红帽Linux故障定位技术详解与实例(1) 2011-09-28 14:26 圈儿 BEAREYES.COM 我要评论(0) 字号#xff1a;T | T在线故障定位就是在故障发生时, 故障所处的操作系统环境仍然可以访问#xff0c;故障处理人员可通过console, ssh等方式登录到操作系统上#xff0c;在shell上执行…红帽Linux故障定位技术详解与实例(1) 2011-09-28 14:26 圈儿 BEAREYES.COM 我要评论(0) 字号T | T 在线故障定位就是在故障发生时, 故障所处的操作系统环境仍然可以访问故障处理人员可通过console, ssh等方式登录到操作系统上在shell上执行各种操作命令或测试程序的方式对故障环境进行观察分析测试以定位出故障发生的原因。 AD2014WOT全球软件技术峰会北京站 课程视频发布 红帽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信息能直接定位出导致终止信号的代码位置. 另外, SIGQUITSIGABRT一般是由用户代码自己使用的好的代码一般会记录日志. 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掉了. 转载于:https://www.cnblogs.com/L-H-R-X-hehe/p/3963496.html
