Linux死机问题分析定位

1、一、现象初步判断：1、判定是否死机：首先需要确定是否真正的死机了，而往往有些现象被现场误认为是死机了。是否死机的确定方法有如下：a、对于直接死掉的，没有任何反应的情况下，看看键盘输入是否有效，putty是否能够登 陆，bmc是否能够登录；通过last reboot确认是否死机？死机的时间？# last rebootrebootsystem boot 27-de tue sep 13 09:43(14+06:14)rebootsystem boot 20.7de fri sep 9 07:46(4+01:54)wtrop begins fri sep 9 07:4

2、6:42 2011c通过在messages屮对应的时间点看是否有imklog启动的日志？并在这个时i'可点前是否收到关机信号或者异常打印？20丄1卩§27丁68:50:0 962299+00:00 啰 vyftpd: tue sep 27 0858:06 201 丄pid 30095 ftploguseir ok login: client 492丄68丄6丄 5l 20丄丄10927丁丄0:47注< 445丄8800:00 他 kernel: imklog 45771og source = /proc/kasg started.d、通过在boot.msg屮对应吋间点有

3、启动的相关记录，并同吋查看在boot.omsg中是否有关机的相关tl志打印？shut;ting down httzpd2 (walking for all children to terminate) done<notice sep 13 09:41: 32.768865000> * apche2 stop* exits with0<notice sep 13 09:41:32.769895000> cron stopshutting down cron daemon搜索：shutting down关键字看是否存在关机2、是否人为操作出现系统重启现彖，往往被认为是系统死

4、机后然后重启的，这就通过重启现彖了来认为系统死机过，但是这种系统重启是否是由于死机造成的，需要进行确定。a、通过同现场人员进行沟通，确认是否为人为的重启？比如按电源、拔电源等人为动作？ba通过history中查询在系统重启时的时间点附近有reboot或halt、shutdown> init?mn:* # cd /varmn:/var # history » history.txtc、通过在bmc h志中确认是否有通过bmc的操作进行系统的重启操作？对于直接拔电源致使系统重启的操作，在messges和boot.omsg中是没冇相关的信息记录 的，表现为系统tl志和业务运行日志在同

5、一时间全部消失。对于按电源、命令进行重启操作，在messages中能够看到系统收到关机或者重启的信息， 同时在b oot.omsg>|哙有关机时的关闭系统服务的关机过程信息。对于在bmc.h直接进行关机或者重启操作，信息记录就比较复杂了。而对于此种情况, 在messages中和boot.omsg中是看不到相关的信息记录，同直接拔电源一样的。二、处理步骤：1、日志尽快获取：在现场反馈出现死机问题后，第一时间反馈相关日志，并尽量多尽量准确全面，等待的 时i'可越长口志可能就已覆盖，或清除，或环境重搭，致使定位工作受到阻碍。a、死机问题发生的时间点如果发生死机问题时测试或维护人员在场，

6、需反馈死机问题发生的精确时i'可。b、死机具体现象描述死机问题的发生通常伴随着系统和业务方面的异常现象，系统异常包括服务器重启、系 统挂死（如bmc黑屏）、系统迟缓（如命令无法执行或响应吋间过长）、网络中断（如ping 检测失败）、登陆失败（如无法远程登陆或卡死在登陆界而）、文件系统异常（如文件只读 或系统命令失效）等等；操作失败、超时、执行无返回等。项目结果服务器重启ok/nok系统挂死（bmc或kvm黑屏）iok/nokj系统延缓（如命令无法执行或响应时间过长）ok/nok网络中断（如ping检测失败）ok/nok登陆失败（如无法远程登陆或卡死在登陆界面）ok/nok文件系统异常（

7、如文件只读或系统命令失效）ok/nok业务异常则包括主备haok/nok操作失败ok/nok |命令执行超时ok/nok此外，同样现象的死机问题是否多次出现、出现频率也需要反馈。c、死机时段具体操作主要指死机时段内对整个系统（包括硬件和软件）进行的各种操作，包括但不限于对服 务器上下电、更换硕件、拔插网线、更改交换机配置、监控及日志查询。此外还包括死机之前对问题服务器的各种操作，如执行脚本或系统命令、拷贝/删除/修 改文件、启动/停止系统服务、挂载木地或远端目录等。2组网、硬件和bmc信息反馈组网、硬件信息有助于定位人员从宏观把握整个系统以及借鉴之前的经验，而内置在服 务器中bmc系统收集的信

8、息有时更能为死机问题定位提供直接的依据。a、组网信息组网信息主要包括网络规模（服务器、交换机数目）、硬件类型（防火墙、服务器、交 换机型号）、网络配置（ip地址规划、交换机配置）、物理连线图等。b、硬件信息硬件信息主要包括发生死机的服务器类型（rh2285、e6000、t6000或其它服务器）、 cpu型号与数目、内存大小、本地硕盘容量与数目、bios配置等，此外建议信息收集人员 尽可能反馈组网内其它服务器、其它设备的硬件信息，便于定位人员横向对比。服务器各种硬件信息查询如下：（1）cpu型号与数目对于管理、存储节点,使用“cat/proc/cpuinfo”命令获得；对于计算节点使用“cat/

9、proc/cpuinfo”仅能获得domaino中的cpu信息，可以通过"xm dmesg”命令查看所有的cpu信息。processor:15:genuinelncelipu family;6nodel! 26nodel name;intel(r) xeon(r) cpue5530 2.40ghzstepping:5?pu hhz:z-iuo.muache size:8192 kbphysical id:0siblings! 8?ore id! 3?pu cores;4sipicid:7initial «picjd:7fpu:yesfpu_exception;yes二pui

10、d level:11wp:yescleigs;fpu vme de pse tsc rosr pae race cx8 aplc sep mtrr pge mca cmov pprfmon pebs bts repgood xcopology nonscop_tsc aperfwperf pnimonitor ds dept vpidoogomlps;4800.36rlflush size! 64achealignmenc ! 64address sizes:40 bits physical/ 48 bits virtualpower management:1（2）内存大小对于管理、存储节点，

11、使用“cal/proc/mcminfo”命令获得；对于计算节点使用“cal/proc/meminfov仅能获得domaino111的内存信息，可以通过“xmdmesg"命令查看内存总大小。cat/proc/roeromfomemtotdl:16295224 kbmemfree:7860712 kbbuffers:687856 kbcached:5706456 kbswapcached:0 kbactive:7048156 kbinactrve:582716 kbactive(anon):1242848 kbinactive(anon):0 kbactive(file):5805308

12、 kbinactive(file):582716 kb(jnevictable:0 kbmlocked:0 kbswaptotal:2104472 kbswapfree:2104472 kbdirty:556 kbwriteback:0 kbanonpages:1235360 kbmapped:31404 kb5hmem:7496 kbslab:727812 kbsreclaimable:406524 kbsunreclairo:321288 kbkernelstack:4864 kbpagetables:12268 kbvfs_unstable:0 kbbounce:0 kburitebac

13、ktmp:0 kbcontnltllmlt:10252084 kbcontnitted_as:3787376 kb7n)alloctotal:34359738367 kb7mallocused:339584 kb7mallocchunk:34359395324 kbharduarecorrupted:0 kb（3）本地硬盘容量与数目本地硬盘容量可以通过“fdisk-l”命令获得，考虑raid组以及挂载远端磁盘的因素，本地硬盘数目最好通过bmc界面直接查看，在bmc界面，系统信息系统状态中可以看到硬盘槽位和硬盘状态。j:/proc # fdisk-1disk /dev/sdb: 1000.2 g

14、bz 1000204886016byteshss heads# 63 sectors/track,121601 cylindersunits cylindersof16065 »512 - 8225280 bytesdisk identifier:0x9f5470abdevice bootstartendblocksidsystem/dev/sdbl1130610490413+5extended/dev/sdb513933156709+83linux/dev/sdb6394786315674183linuxdisk /dev/sda: 1000.2 gb# 1000204886016

15、bytesp5s heads# 63 sectors/track/121601 cylindersunits cylindersof16065 512 - e225280 bytesdisk identifier:0x00000000device bootstat tendblocksidsystem/dev/sdal12 622104483+82linux swap / solaris/dev/sda22 63417931463302+83linux/dev/sda3418067s020972857+83linux/dev/sda467911216c0922211325sextendedde

16、v/sdas679194012097282683linux/dev/sda69402120122097285783linux/dev/sda7120132506710486428783linux/dev/sda8250681216c077540132283linux3、bmc信息bmc是公司自研的rh2285、e6000、t6000等型号服务器内嵌的服务器管理控制单元， 能够实现对服务器的多种管理、查询、监控功能，发生死机问题时需要从bmc收集的信息 包括（1）bmc系统事件日志登陆bmc提供的web界血后，查看系统日志事件，反馈死机发生吋i'可点前后-段吋i'可（建 议取死机

17、发生前后12小时）的h志截图。通过ftp方式登陆bmc的文件系统，反馈data目录下的sel.bin文件。（2）bmc、bios 版本号在bmc的web界面，选择系统信息> 固件版本查询，反馈版本信息：（3）bmc与os的时间差由于bmc和os使用不同的时间芯片，因此这两者z间可能存在时间差，需要现场人员 通过登陆bmc系统和os进行时间的比对，并截图表示两者之间的时间差异，这样便于定位 人员分析bmc日志和os的日志（时间差）。三、系统信息linux的口志系统能够记录系统的登陆情况、操作记录、异常事件等，多数情况下为系 统侧死机问题提供重要的线索，发生死机问题时，建议从系统方面获得如下

18、信息：1 系统message日志系统的messageh志会记录在cd /var/log/目录下，并根据日志产生时间和日志文件大小压 缩备份为“messages时间戳>.bz”的形式，请尽可能在反馈全部的日志文件（包括当前日 志文件/var/log/messages以及所有的bz压缩文件）。3、系统boot日志操作系统能够记录当前和前一次启动时的口志，两次启动记录保存在/var/log/boot.msg 和/var/log/boot.omsg中,请全部反馈。4、系统登录和使用情况使用last可以查看系统每次启动的时i'可点、用户登陆情况等，建议使用：ulast reboot

19、87; last.txt?，命令将last命令的执行结果保存为文本文件进行反馈。5、系统历史操作记录使用histoiy可以查看系统的历史操作信息，建议使用“history >> history.txt”命令将 history命令的执行结杲保存为文本文件进行反馈。6、系统黑匣子记录系统屮提供黑he子功能收集节点操作系统crash （如panicx oops> bug、oom等）时的 异常信息，黑匝子功能实现的机制和记录存放位置不同，请注意按照不同的操作系统类型和 发生死机的时间反馈对应的黑匣子日志。系统监控记录galax系统提供对操作系统各种资源进行监控的功能，并生成监控口志保

20、存在每个节点 的/opt/osinfo/statistics/目录中，监控日志会根据大小和时间在同一目录下保存为ustatistics< 时间戳格式，请注意按照发生死机的时间反馈对应的系统监控日志。a、系统串口消息如杲出于调测的目的开放系统的串口，请反馈问题服务器的串口打印信息，通常情况下 galax系统中各个节点的串口功能是关闭的。串口打印的堆栈信息、临终遗言对死机定位非常有用，如果没有部署串口，请尽量将串 口部署上，串口信息对于死机问题的定位很重要。b、底层日志：c、收集系统的打印信息：命令：cat /proc/sys/kernel/printk# cat /proc/sys/ker

21、nel/printk14171、定位方法1 是否硬件狗复位a. 在死机问题中，较多的死机问题都是由于软件狗未喂硕件狗，或者喂狗不成功，导致 硬件狗超时（超时时间为20min）,从而重启服务器，这样就认为系统死机后的重启。b. 因此查看watchdog的日志，看是否是喂狗的时候出现问题.首先需要判定是否由于 watchdog自身的原因或者某些规则导致硬件狗超时而重启服务器，这样的原因下就是上层业 务造成的，不是os本身的问题。c. 同时在查看watchdog的日志时，注意查看是否是喂狗的脚本执行不成功？有无及时的 返回喂狗脚木执行的结杲？这样判定是否是由于喂狗脚木阻塞引起的硕件狗超时？同时比 对

22、是否在其它的业务模块日志中也有执行脚本不成功的情况？这样如果所有的模块都存在 这种执行脚本不成功、卡死的话，那就不是watchdog本身的原因，而是在系统中的其它原因 造成，需要向系统更深入的排查原因了。如果是由硬件狗复位服务器，在bmc界面日志中能够记录到相应的日志，通过此可以进 行判定；2. 是否系统负载过高linux系统不是孤立的存在的，其上往往是运行这产品自身的业务，而业务既然使用语 言代码编程，那也就存在bug,而对于这些bug也可能引起linux的崩溃或者类似死机的现象。这类问题往往最常见的现象是系统响应缓慢，或者无法响应，从而认为系统死机，这往 往从监控口志屮能够看到内存和cpu

23、使用飙高，而这往往是由于系统负载过高导致的。由于系统负载过高导致的卡死，一定是解决的越快越好！需要通过命令行终端进行定位。 通过clrl + all+fl（通常f1-f6都可以进行切换），此时可能键盘的输入速度比较慢，请耐性 等候，在提示符后输入top回车，看到一张动态的表，上而列出了耗用资源最多的进程。观 察到刷新儿次后，按q退出，然后输入kill pid,其中pid为top中显示的占用资源较多的进程， 此时系统应该会快不少，如果没有结束掉进程，通过kill -9,这样基本上没有问题了（这个动 作一般不要做）。ipiduserprnivirtresshr s% cpu% mehtime+co

24、mmand"091rooc3919000s280.0764:19.88kipmio32root200000s100.0396:51.92ksoftirqd/1416root200000s90.0421:41.96ksoftirqd/627981root1464720m63m8864s30.4144:44.46java2208root20089001336856r10.00:00.26top4119root2008968628420s00.05:08.89irqbalancem99postgres200673001456496s00.02:27.83postmaster4360root

25、200323m218n2352s01.443:21.55perl27297root200206m17961020s00.049:19.08rsyslogd1root20010376784652s00.00:44.07init2root200000s00.00:00.00kthreadd3rootrt0000s00.00:07.13mlgration/0qroot200000s00.0501:14.50ksoftirqd/05rootrt0000s00.00:06.62migratlon/16root200000s00.0322 :10.83ksoftirqd/l7rootrt0000300.0

26、0:07.48migration/28root200000s00.0326:48.78ksoftirqd/29rootrt0000s00.00:07.16migratlon/310root200000s00.0397:14.96ksoftirqd/311rootrt0000s00.00:06.36roigration/412root200000s00.0394:26.52ksoftirqd/43. 是否业务导致判断到是由于系统的负载过高导致系统的死机，然后就是判泄是否是由于业务导致的？业务模块相对来说是一个比较新开发的，出现问题的儿率还是相对来说比较人的。因此 首先是从业务模块下手。1. 在出

27、现间题时，现场是否做了哪些的操作？2. 而这些操作是否会引起某些系统资源的过载使用？3. 结合业务模块的日志，分析在出现问题时是否有某些异常的日志记录？4. 如果有，则找到出现这些异常的原因，向上找到出现这些异常的起始点，再向上查 找比较长的时间段日志，看是否有明显的异常。4. 是否硬件相关因此首先需要同判定现场坏境中的bios中的某些项的设置是否正确？看当时配套版本屮说明的设置，以及此版本是否本身就存在此问题？在判定完上述后，如果都不符合，则有可能是出现了新的问题，获取到messages和监控 日志等，在其中进行查看是否有报硬件相关的错误，针对这些错误，判断分析是否正常？而 同时这些错误有可

28、能在出现问题之前比较长的时间，需要向上冋溯。需要专业硬件人员来分析。5. 是否内核问题问题与kernel可能也有关系了，而如果同kernel有较大关系的话，系统会产生kbox文件, 而管理节点由于使用linuximg,则产生的黑匣子日志文件在本地/var目录下，计算节点采用 的是smartuvp,则产生的黑匣子日志文件会存放在tftp服务器上，在galax系统中，通常 使用mn节点作为tftp服务器，所以对应计算节点的黑匣子口志保存在mn节点的/tftpboot 目录中。通过黑盒子或者串口信息基本就能确认，需要查看源代码一起分析。部署串口串口信息分析:&$8080s593s2 d&qu

29、ot;id "or: 0000【叫】 * j(9s8080.so439j (9s8o8o.s69403)(9s8080.s7k42) (9i8080.«7183j(9s8080.m0880j (pid: nkip：rsf：rax：mx lrbp：m01lest y幺 til: /ys/module/drbd/par<m«t«r*/cnsidx cfu smodules linked in: 8021q gerp tp 11c drbd(n) bndxrm ipmi_d«vin supported: yes, external(9s9090

30、s0938) (9s8080.6s9601j (9)6080.<65223) (9s8080.«72s13) (9)8080.*79804) (9$e080.m7098) (9s8080.(94382)(9s8080 701671)fps: r»8080.70»05kc3? (9s8080.71s7«j (9)8080.723049) (9s8080.730343) (9s8080.737<29) (9j808o.74wooj (9s8080.748436) (958080.7ss801) (9s8080.763675j (>$8080

31、.771546) (9s8080.779420) (9s8080.787s2o os8080.790106j (9$e080.79(317) (9$8080.«02008) os8080.807265 (9s8080.8122s9) (>$8080.817339)s 2.«.32.12-0.7-det<ult fl tecel bk620teinttd: p:0010sfffffff81046c44>) 0018:ff<<880c09«edcl0 oooooooooooooooo oooooooooooooooo ftft880c09

32、e<dd80 oooooooooooooooooooooooooooooooomx imilm)8:kll:k14:f f f f f f8104<e44>) fxnd bu«x« 宅 bpiag3: 00010046ttttttititttittt00000000000000180000000000000018ooooooootttt<tftoooooooot<<<<ff<kcxlmilr09:ml2i0000000000000001 oooooooooooooooo fftt8800282«e<900

33、000000000013480任务p【dl"roup*0x<34/0x9b00000000000000000(0000f gs： ftf <8800282«0000(0000) knlgs:000000000000000000x0 ds: ooxb 001。cko: 00000000800s003bc池：00007t73280731c8 cr3: 0000000001804000 cm: oooooooooooooceodm): 0000000000000000 dr1: 0000000000000000 dr2: 0000000000000000dk3i 000000000000