1、紅帽linux故障定位技術(shù)詳解與實(shí)例紅帽linux故障定位技術(shù)詳解與實(shí)例是本文要介紹的內(nèi)容,主要是來了解并學(xué)習(xí)紅帽linux中 故障定位技術(shù)的學(xué)習(xí)，故障定位技術(shù)分為在線故障定位和離線故障定位，一起來看詳解。1、故障定位(debugging)場景分類為便于描述問題，將linux上各種軟件故障定位的情形分成兩類：(1) 在線故障故障定位在線故障定位(online-debugging)就是在故障發(fā)生時(shí)，故障所處的操作系統(tǒng)環(huán)境仍然可 以訪問，故障處理人員可通過console, ssh等方式登錄到操作系統(tǒng)上，在shell上執(zhí)行各種操 作命令或測試程序的方式對故障壞境進(jìn)行觀察，分析，測試，以定位出故障發(fā)生

2、的原因。(2) 離線故障定位離線故障定位(offline-debugging)就是在故障發(fā)牛時(shí)，故障所處的操作系統(tǒng)環(huán)境已經(jīng)無法 正常訪問，但故障發(fā)生時(shí)系統(tǒng)的全部或部分狀態(tài)已經(jīng)被系統(tǒng)本身所固有或事先設(shè)定的方式收集起 來，故障處理人員可通過對收集到的故障定位狀態(tài)信息進(jìn)行分析，定位出故障發(fā)生的原因。2、應(yīng)用進(jìn)程故障情形及處理應(yīng)用進(jìn)程的故障一般不會(huì)影響操作系統(tǒng)運(yùn)行環(huán)境的止常使用(如果應(yīng)用代碼的bug導(dǎo)致了 內(nèi)核的crash或hang,則屬于內(nèi)核存在漏洞)，所以可采用在線故障定位的方法，靈活的進(jìn)行 分析.應(yīng)用代碼故障的情形有如下幾種：(1) 進(jìn)程異常終止很多用戶認(rèn)為進(jìn)程異常終止情況無從分析，但實(shí)際上進(jìn)程

3、異常終止情況都是有跡可尋的.所 有的進(jìn)程異常終止行為，都是通過內(nèi)核發(fā)信號給特定進(jìn)程或進(jìn)程組實(shí)現(xiàn)的.可分成兒個(gè)類型進(jìn)行 描述：sigkill. sigkill最特殊，因?yàn)樵撔盘柌豢杀徊东@，同時(shí)sigkill不會(huì)導(dǎo)致被終止的進(jìn) 程產(chǎn)生core文件，但如果真正的是由內(nèi)核中發(fā)出的sigkill,則內(nèi)核一定會(huì)在dmesg中記錄 下信息.另外在內(nèi)核中使用sigkill的地方屈指町?dāng)?shù)，如oom_kill_process()中，所以通過 dmesg記錄并且分析內(nèi)核中使用sigkill的代碼，并不難分析原因-sigquit, sigill, sigabrt, sigbus, sigfpe, sigsegvo 這

4、幾個(gè)信號在保留情 況下會(huì)終止進(jìn)程并會(huì)產(chǎn)生core文件，用戶根據(jù)core中的stack trace信息，能直接定位出導(dǎo)致 終止信號的代碼位置。另外，sigquit, s1gabrt -般是由用戶代碼自己使用的，好的代碼一 般會(huì)記錄日志。sigill, sigbus, sigfpe, sigsegv,都是由內(nèi)核屮產(chǎn)生的，搜索內(nèi)核源 碼，不難列出內(nèi)核屮使用這幾個(gè)信號的地方，如sigill是非法指令，可能是浮點(diǎn)運(yùn)算產(chǎn)生的代 碼被corrupted或文本區(qū)域的物理內(nèi)存corruption； sigbus多由mce故障定位導(dǎo)致:sigsegv 多由應(yīng)用代碼的指針變量被corrupted導(dǎo)致。對于應(yīng)用的he

5、ap或stack的內(nèi)存被corrupted,可 用valgrind工具對應(yīng)用進(jìn)行profile,通常能直接發(fā)現(xiàn)導(dǎo)致corruption的代碼sigint, sigpipe, sigalrm, sigterm-這幾個(gè)信號在保留情況下終止進(jìn)程但不會(huì)產(chǎn) 牛core文件。對這幾個(gè)信號，建議用戶一定要定義一個(gè)handler,以記錄產(chǎn)生問題的上下文。 比較容易忽略的是sigpipe,很多用戶程序在使用selector poll()時(shí)只監(jiān)聽read/write描述符， 不監(jiān)聽exception描述符，在對方tcp己經(jīng)關(guān)閉的情況下,仍然向socket中寫入，導(dǎo)致sigpipe。對于惡意的代嗎產(chǎn)生的進(jìn)程終止行為

6、，如合作的一些進(jìn)程屮，a向b發(fā)sigkill,而沒做 日志記錄，或者b直接判斷某條件而調(diào)用exit(),也沒有做日志記錄在應(yīng)用代碼量很大的情況下, 通過分析代碼故障定位這種情形也許很難.systemtap提供了解決這個(gè)問題的一個(gè)比較好的方 法，就是寫用八層的probes,追蹤進(jìn)程對signal(), exit()等系統(tǒng)調(diào)用的使用(2) 進(jìn)程阻塞，應(yīng)用無法正常推進(jìn)這種情況，對于單個(gè)被阻寒的進(jìn)程而言，屬于正常狀態(tài)，但對于包含多個(gè)進(jìn)程的應(yīng)用整體而 言，屬于異常。應(yīng)用無法推進(jìn)，說明其中某一個(gè)進(jìn)程推進(jìn)的因素出現(xiàn)了問題，導(dǎo)致其他依賴于它 的進(jìn)程也要等待.分析這種情形需要分析清楚進(jìn)程或事件之間的依賴關(guān)系，及

7、數(shù)據(jù)的處理流。首 先要用gdb -p的back trace功能查出各進(jìn)程阻塞的執(zhí)行路徑，以確定每個(gè)進(jìn)程所處在的狀態(tài)機(jī) 的位置。通常而言，如果只考慮各個(gè)進(jìn)程的狀態(tài)，則進(jìn)程之間可能形成了一種互相依賴的環(huán)形關(guān)系, 如(p1發(fā)請求=>p2處理=>p2發(fā)反應(yīng)=>p1再請求=>p2處理=>p2再發(fā)反應(yīng))，但應(yīng)用對 workload,般是按一個(gè)個(gè)的transaction或session的方式進(jìn)行處理的，每個(gè)transaction都 有起點(diǎn)和終點(diǎn)，我們需要用strace, tcpdump等工具以及應(yīng)用的執(zhí)行日志進(jìn)行觀察，分析出當(dāng) 前正被處理的transaction所被阻滯的位置，

8、從而找出全部狀態(tài)機(jī)被阻塞的原因。導(dǎo)致這種狀態(tài) 機(jī)停止運(yùn)轉(zhuǎn)的原因有多個(gè)：如和應(yīng)用通信的遠(yuǎn)端出現(xiàn)了問題，后端數(shù)據(jù)庫/目錄等出現(xiàn)了問題， 應(yīng)用的某個(gè)進(jìn)程或線程處于非正常的blocking位置或直接終止，不再正常工作。(3) 用戶進(jìn)程形成死鎖用戶進(jìn)程形成死鎖，如果沒有內(nèi)存上的故障定位，則完全是應(yīng)用自身的邏輯問題。死鎖的進(jìn) 程或線程z間由于鎖的互相占有形成了環(huán)路。這種情況發(fā)生時(shí)，用gdb -p的back trace的功能 能直接確定死鎖的進(jìn)程全部阻塞在futex()等和鎖相關(guān)的系統(tǒng)調(diào)用上，這些調(diào)用futex()的路徑可 能是 mutex, semaphore, conditional variable

9、等鎖函數(shù)。通過分析 call trace 的代碼，能 直接確定各進(jìn)程在執(zhí)行到該位置時(shí)，可能已經(jīng)持有的全部鎖，根據(jù)這個(gè)修改程序的代碼，消除死 鎖環(huán)路，就可解決問題。注意，內(nèi)存故障也可導(dǎo)致假的死鎖的，如物理內(nèi)存故障可直接導(dǎo)致鎖變量的值為-1,所以使 用該鎖的進(jìn)程都會(huì)阻塞.如果是代碼的bug導(dǎo)致的內(nèi)存corruption,可用valgrind i具檢查程序 來發(fā)現(xiàn)。但如果是物理內(nèi)存的故障定位導(dǎo)致的corruption,則需耍硬件的支持，對于高端的pc, 如mce功能的機(jī)器，當(dāng)物理內(nèi)存故障定位時(shí)能直接產(chǎn)生異常或報(bào)告，但對于低端pc服務(wù)器， 除了運(yùn)行memtest工具進(jìn)行檢測外，沒有其他方法。(4)進(jìn)程

10、長期處于 d (uninterruptible)狀態(tài)沒法退出這種多是由內(nèi)核中的故障引起的。內(nèi)核在很多執(zhí)行路徑中會(huì)將進(jìn)程至于'd的狀態(tài)，以確保 關(guān)鍵的執(zhí)行路徑不被外部的信號中斷，導(dǎo)致不必要的內(nèi)核中數(shù)據(jù)結(jié)構(gòu)狀態(tài)的不一致性。但一般而 言，進(jìn)程處于狀態(tài)的時(shí)間不會(huì)太久，因?yàn)闋顟B(tài)結(jié)朿的條件(如timer觸發(fā)，i0操作完成等) 很快會(huì)將進(jìn)程喚醒.當(dāng)進(jìn)程長期處于關(guān)鍵是要找出其阻塞的代碼位置，用sysrq的t鍵功 能可直接打印出系統(tǒng)屮全部睡眠進(jìn)程的內(nèi)核執(zhí)行堆棧，如echo't* >/proc/sysrq-trigger,其中包 括出現(xiàn)d狀態(tài)的進(jìn)程的內(nèi)核態(tài)堆棧。找出代碼位置后，一般可直接分析

11、出d狀態(tài)不能退出的 原因，如loread操作因碩件或nfs故障而不能完成。有可能導(dǎo)致d狀態(tài)的原因比較復(fù)雜，如 'd，的退出依賴于某變量的值，而該變量的値因某種原因被永久corrupted掉了。3、內(nèi)核故障情形及處理(1) 內(nèi)核 panicpanic是內(nèi)核最直接的故障定位報(bào)告，發(fā)生panic時(shí)，內(nèi)核已經(jīng)認(rèn)為故障定位已經(jīng)導(dǎo)致操作 系統(tǒng)不再具備正常運(yùn)行的條件了。當(dāng)發(fā)牛panic時(shí)，linux會(huì)將所冇cpu的中斷和進(jìn)程調(diào)度功 能都關(guān)掉，所以這時(shí)系統(tǒng)是沒有任何反應(yīng)的，如果用戶啟動(dòng)的是圖形界面，則在屏幕上也看不到 任何關(guān)于panic的信息。我們通常遇到的，機(jī)器沒反應(yīng)，ping不通的情況，絕大部分都

12、是panicc panic發(fā)生時(shí)， 內(nèi)核直接在console上打印導(dǎo)致panic的代碼位置的調(diào)用堆棧，傳統(tǒng)的用戶用串口連接到機(jī)器上 來收集console上的打印信息，但串口這種方式，顯然用起來不方便，現(xiàn)在的linux,如rhel5, rhel6,都采用kdump的方法來收集panic時(shí)的信息。在配置好kdump的情況下，panic時(shí)系 統(tǒng)會(huì)用kexec加載并切換到一個(gè)新的內(nèi)核上（放置在預(yù)先分配的內(nèi)存位置），并用磁盤或網(wǎng)絡(luò) 等將系統(tǒng)的全部或部分內(nèi)存數(shù)據(jù)保存起來。用kdump收集到panic的數(shù)據(jù)后,用戶用crash工具就能直接查看導(dǎo)致panic的代碼路徑。panic 一般是很直觀的，panic的

13、堆棧信息能直接反映出導(dǎo)致bug的原因，如mce故障， nmi故障,數(shù)據(jù)結(jié)構(gòu)分配失敗等。但有時(shí)panic是因?yàn)閮?nèi)核主動(dòng)發(fā)現(xiàn)了關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)不一致性, 這種不一致性是什么時(shí)候，什么代碼導(dǎo)致的，并不清楚，可能還需要多次測試用systemtap這 樣的工具進(jìn)行捕捉（2）多處理機(jī)環(huán)境內(nèi)核執(zhí)行路徑產(chǎn)生的死鎖內(nèi)核死鎖和panic不一樣，產(chǎn)牛死鎖時(shí)，內(nèi)核并不主動(dòng)的使自己處于掛起狀態(tài)。但內(nèi)核死 鎖發(fā)生時(shí)，兩個(gè)以上的cpu的執(zhí)行路徑在內(nèi)核態(tài)不能推進(jìn)了，處于互相阻塞狀態(tài)，而且是100% 的占用cpu （用的spin-lock）,直接或間接的導(dǎo)致全部cpu上的進(jìn)程無法調(diào)度。內(nèi)核死鎖又 分兩種情況：涉及到中斷上下文的死

14、鎖。這種情況的死鎖，最少一個(gè)cpu上的中斷被屏蔽了。系統(tǒng)可 能沒法響應(yīng)ping請求。山于有一個(gè)cpu己經(jīng)沒法響應(yīng)中斷，其上的local apic定時(shí)中斷沒法 工作，可以用nmi watchdog的方法來檢測出來（檢查local apic handler維護(hù)的計(jì)數(shù)器變量）， nmi watchdog可以在其處理程序中調(diào)用panic （）,用戶就可以用kdump收集內(nèi)存信息，從 而分析各死鎖cpu上的調(diào)用堆棧，查處導(dǎo)致死鎖的邏輯原因。不涉及中斷上下文的死鎖。這種情況的死鎖，各cpu上的中斷都是正常的，系統(tǒng)能對 ping請求作出反應(yīng)，這時(shí)nml watchdog無法被觸發(fā)。在2。6。16之前的內(nèi)核屮

15、，并沒有一 種很好的方法來處理這種情形。在rhel5, rhel6內(nèi)核屮，每個(gè)cpu ±提供了一個(gè) watchdog內(nèi)核線程，在死鎖出現(xiàn)的情況下，死鎖cpu上的watchdog內(nèi)核線程沒法被調(diào)度（即 使它是最髙優(yōu)先級的實(shí)時(shí)進(jìn)程），它就沒法update相應(yīng)的counter變量，各cpu的nmi watchdog 中斷會(huì)周期性的檢查其cpu對應(yīng)的counter,發(fā)現(xiàn)沒有updated,會(huì)調(diào)用panic （）,用戶就 可用kdump收集內(nèi)存信息，分析各死鎖cpu上的調(diào)用堆棧，查處導(dǎo)致死鎖的邏輯原因。(3) 內(nèi)核的 oops 或 warningoops和warning和panic類似的地方是

16、，他們都是因內(nèi)核發(fā)現(xiàn)了不一致而主動(dòng)報(bào)告的異常。 但oops和warning導(dǎo)致的問題嚴(yán)重程度要比panic輕很多，以致于內(nèi)核處理該問題時(shí)不需要使 系統(tǒng)掛起。產(chǎn)生oops和warning,內(nèi)核通常已經(jīng)在dmesg中記錄了相當(dāng)?shù)男畔?特別是oops, 至少會(huì)打印出現(xiàn)故障的地方的call traceo oops也可轉(zhuǎn)換成panic/kdump來進(jìn)行 offline-debugging,只要將/proc/sys/kernel 下的 panic_on_oops 變量設(shè)置為 1 就行了。產(chǎn)生oops和warning的直接原因有很多，如內(nèi)核中的segment fault,或內(nèi)核發(fā)現(xiàn)的某數(shù) 據(jù)結(jié)構(gòu)的count

17、er值不對，而segment fault和counter值的變化還冇更深層次的原因，通常并 不能從內(nèi)核dmesg的信息屮看出來，解決這種問題的是要用systemtap進(jìn)行probe,如發(fā)現(xiàn) 某counter的值不對，就用systemtap做一個(gè)probe來記錄所有代碼對該counter的訪問，然 后再進(jìn)行分析。定位oops和warning會(huì)比定位應(yīng)用程序的內(nèi)存訪問故障定位困難很多，因?yàn)樵趦?nèi)核并不能 象用valgrind去trace應(yīng)用程序一樣跟蹤數(shù)據(jù)結(jié)構(gòu)的分配和使用情況。2、其他(硬件相關(guān))故障機(jī)器自動(dòng)重啟是一種常見的故障情形，一般是由硬件如物理內(nèi)存故障引起的，軟件的故障只 會(huì)導(dǎo)致死鎖或pan

18、ic,內(nèi)核屮幾乎沒有代碼在發(fā)現(xiàn)問題的情況下去reboot機(jī)器。在 /proc/sys/kernel冃錄下有個(gè)參數(shù)panic”，其值如果設(shè)置為非0,則在panic發(fā)牛若干秒后，內(nèi) 核會(huì)重啟機(jī)器。現(xiàn)在高端的pc服務(wù)器，都在努力用軟件來處理物理內(nèi)存故障，如mca的 “hwpoison”方法會(huì)將故障的物理貝隔離起來，kill掉故障頁所在的進(jìn)程就可以了，rhel6現(xiàn)在 已經(jīng)支持“hwpoison”。那些不具備mca能力的機(jī)器，物理內(nèi)存故障時(shí)，不會(huì)產(chǎn)生mce異常， 直接由硬件機(jī)制reboot機(jī)器4、rhel6上的debugging技術(shù)介紹(1) kdump故障定位收集和crash分析kdump就是用來在內(nèi)

19、核panic的情況下收集系統(tǒng)內(nèi)存信息的，用戶也可在online情況下用 sysrq的'c'鍵觸發(fā)。kdump采用沒有污染的內(nèi)核來執(zhí)行dump工作，所以其比以前的diskdump, iked方法更可靠。使用kdump,用戶可選擇將數(shù)據(jù)dump到本地盤或網(wǎng)絡(luò)上，也可通過定義 makedumpfile的參數(shù)過濾要收集的內(nèi)存信息，己減少kdump所需更的停機(jī)時(shí)間crash就是對kdump的信息進(jìn)行分析的工具。其實(shí)際就是gdb的一個(gè)wrapper。使用crash 時(shí)，最好安裝kernel-debuginfo包，這樣能解析kdump收集的內(nèi)核數(shù)據(jù)的符號信息。用crash 來定位問題的能力，

20、完全取決于用戶對內(nèi)核代碼的理解和分析能力參考 “#>man kdump。conf”，“#>man crash”，u#>man makedumpfilem學(xué)習(xí)怎樣使用 kdump 和 crash。訪問 http： /ftp。redhato com 可下載 debuginfo 文件(2) 用 systemtap 定位 bugsystemtap屬于probe類的定位工具，它能對內(nèi)核或用戶代碼的指定位置進(jìn)行probe,當(dāng)執(zhí)行到指定 位置或訪問指定位置的數(shù)據(jù)時(shí)，用戶定義的probe函數(shù)自動(dòng)執(zhí)行，可打印出該位置的調(diào)用堆棧，參數(shù)值， 變量值等信息。systemtap選擇進(jìn)行probe的位置

21、很靈活，這是systemtap的強(qiáng)人功能所在。systemtap 的probe點(diǎn)可包括如下幾個(gè)方呦：內(nèi)核中全部系統(tǒng)調(diào)用，內(nèi)核及模塊中全部函數(shù)的入口或出口點(diǎn)自定義的定時(shí)器probe點(diǎn)-內(nèi)核屮任意指定的代碼或數(shù)據(jù)訪問位置-特定用戶進(jìn)程屮任意制定的代碼或數(shù)據(jù)訪問位置-各個(gè)功能子系統(tǒng)預(yù)先設(shè)置的若干probe點(diǎn)，如tcp, udp, nfs, signal各子系統(tǒng)都預(yù)先設(shè)置了很多探 測點(diǎn)systemtap的腳本用stap腳本語言來編寫，腳本代碼中調(diào)用stap提供的api進(jìn)行統(tǒng)計(jì)，打印數(shù)據(jù)等 工作，關(guān)于stap語言提供的api函數(shù)，參考*#> man stapfuncs”。關(guān)于systemtap的功

22、能和使用可參考 “#man stap”， “#> man stapprobes*'(3) ftraceftrace是linux內(nèi)核中利用tracepoints基礎(chǔ)設(shè)施實(shí)現(xiàn)的事件追蹤機(jī)制，它的作用在于能比較清楚的給 出在-定時(shí)間內(nèi)系統(tǒng)或進(jìn)程所執(zhí)行的活動(dòng)，如函數(shù)調(diào)用路徑，進(jìn)程切換流等。ftrace可用于觀察系統(tǒng)各部 分的latency,以便進(jìn)行實(shí)時(shí)應(yīng)用的優(yōu)化；它也可以通過記錄一段時(shí)間內(nèi)的內(nèi)核活動(dòng)來幫助故障定位。如用 以卜方法可trace某個(gè)進(jìn)程在一端時(shí)間的函數(shù)調(diào)用情況1.#> echo “function” > /sys/kernel/debug/tracing/curr

23、ent_tracer2.#> echo "xxx” > /sys/kernel/debug/tracing/set_ftrace_pid3. #> echo 1 > /sys/kernel/debug/tracing/tracing_enabled除tracing函數(shù)調(diào)用外，ftrace還可tracing系統(tǒng)的進(jìn)程切換，喚醒，塊設(shè)備訪問，內(nèi)核數(shù)據(jù)結(jié)構(gòu)分配 等活動(dòng)。注意，tracing和profile是不同的，tracing fl錄的是一段時(shí)間內(nèi)的全部活動(dòng)，而不是統(tǒng)計(jì)信息， 用戶口j以通過/sys/kemel/debug/tracing卜-的buffer_siz

24、e_kb設(shè)置緩沖區(qū)的人小，以記錄更長時(shí)間的數(shù)據(jù)。關(guān)丁 ftrace的具體使用町參考內(nèi)核源碼documenation/trace卜的內(nèi)容（4）oprofile 和 perfoprofile和perf都是對系統(tǒng)進(jìn)行profile （抽樣，統(tǒng)計(jì)）的工具，它們主要用來解決系統(tǒng)和應(yīng)用的性能 問題。perf功能更強(qiáng)大，更全而，同時(shí)perf的用戶空間工具和內(nèi)核源碼一起維護(hù)和發(fā)布，讓用戶能及時(shí)的 享受pert內(nèi)核新增加的特征。pert是在rhel6屮才有，rhel5屮沒有pert oprofile和perf都使用現(xiàn) 代cpu中具冇的硬件計(jì)數(shù)器進(jìn)行統(tǒng)計(jì)工作，但perf還町以使用內(nèi)核中定義的“software c

25、ounter”及"trace points'*,所以能做更多的工作。oprofile的抽樣工作利用cpu的nmi中斷來進(jìn)行，而perf既可以利用 nmi中斷也可利用硬件計(jì)數(shù)器提供的周期性中斷。用戶能很容易用perf來oprofile -個(gè)進(jìn)程或系統(tǒng)的執(zhí)行 f寸間分布，如#> perf top -f 1000 -p還口j以利用系統(tǒng)定義的“software counter”和各子系統(tǒng)的“trace points”對子系統(tǒng)進(jìn)行分析，女n#>perf stat -a -e kmem:mm_page_alloc -e kmem:mm_pageree_direct -e km

26、em:mmjdagevec_free sle ep 6能統(tǒng)計(jì)6秒內(nèi)kmem子系統(tǒng)的活動(dòng)（這一點(diǎn)實(shí)際是利用ftrace提供的tracepoints來實(shí)現(xiàn)）我認(rèn)為有了 pert,用戶就沒必要使用oprofile 了5、用kdump工具內(nèi)核故障定位實(shí)例a）部署 kdump部署kdump收集故障信息的步驟如下：（1）設(shè)置好相關(guān)的內(nèi)核啟動(dòng)參數(shù)在/boot/grub/menu.lst中加入如下內(nèi)容crashkernel=128m16m nmi_watchdog=1其中crashkernel參數(shù)是用來為kdump的內(nèi)核預(yù)留內(nèi)存的；nmi_watchdog=1是用來激活nmi 屮斷的，我們在未確定故障是否關(guān)閉

27、了屮斷的情況下，需要部署nml watchdog才能確保觸發(fā) panico重啟系統(tǒng)確保設(shè)置生效（2）設(shè)置好相關(guān)的sysctl內(nèi)核參數(shù)在/etc/sysctl.conf屮最后加入一行kernel.softlookupjdanic = 1該設(shè)置確保softlock發(fā)生時(shí)會(huì)調(diào)用panic,從而觸發(fā)kdump行為執(zhí)行#>sysctl -p確保設(shè)置牛效(3)配置 /etc/kdump.conf在 /etc/kdump.conf屮力fl入如下幾行內(nèi)容1. ext3 /dev/sdb12. core-collector makedumpfile c -message-level 7 d 31 -i /

28、mnt/vmcoreinfo3. path /var/crash4. default reboot其中/dev/sdb1是用于放置dumpfile的文件系統(tǒng)，dumpfile文件放置在/var/crash下，要 事先在/dev/sdb1分區(qū)下創(chuàng)建/var/crash目錄。“d 31”指定對dump內(nèi)容的過濾級別，這參數(shù)對 于dump分區(qū)放不下全部內(nèi)存內(nèi)容或用戶不想讓dumping中斷業(yè)務(wù)太長時(shí)間時(shí)很重要。 vmcoreinfo文件放置在/dev/sdb1分區(qū)的/目錄下,需要使用如下命令產(chǎn)生:#>makedumpfile -g /vmcoreinfo x /usr/lib/debug/li

29、b/modules/2.6.18-128.el5.x86_64/vmlinux“vmlinux”文件是ill kernel-debuginfo包提供的，在運(yùn)行makedumpfile之前需要安裝相應(yīng) 內(nèi)核的 kernel-debuginfo 和 kernel-debuginfo-common 兩個(gè)包,該兩個(gè)包需從 http： /下載。“default reboot”用來告訴kdump,收集完dump信息后重啟系統(tǒng)。（4）激活 kdump運(yùn)行#>service kdump start命令，你會(huì)看到，在成功完成的情況下會(huì)在/boot/目錄下生成 一個(gè) initrd-2o 6., 18-128

30、o el5o x86_64kdumpo img 文件，該文件就是 kdump 加載的內(nèi)核的 initrd 文件，收集dump信息的工作就是在該initrd的啟動(dòng)環(huán)境下進(jìn)行的。查看/etc/init。d/kdump腳本 的代碼，你可看到其中會(huì)調(diào)用mkdumprd命令創(chuàng)建用于dump的initrd文件1 測試kdump部署的冇效性為了測試kdump部署的有效性，本人寫了如下一個(gè)內(nèi)核模塊，通過insmod加載該內(nèi)核模 塊，就能產(chǎn)生一個(gè)內(nèi)核線程，在10秒左右后，占據(jù)100%的cpu,在20秒左右后觸發(fā)kdump., 揮統(tǒng)重啟后，檢查/oracle分區(qū)/vmr/crash冃錄下的內(nèi)容，就能確認(rèn)vmcor

31、e文件是否生成。1 zqfthread.c #inelude2. #include3. #include4. #include5. #include6. #include7.8. module_author("frzhang");9. module_description("a module to test10. module_license(”gpl”)；11.12. static struct task_struct *zqf_thread;13. static int zqfd_thread(void *data);14.15. static int zqf

32、d_thread(void *data)16. 17. inti=o;18.19. while (!kthread_should_stop() 20. i+;21. if (i<10)22. msleep_interruptible(1000);23. printk("%d seconds'”'，i);24. 25. if (i = 1000 ) / running in the kernel26. i = 11 ;27. 28. return 0;29. 30. static int _init zqfinit(void)31. 32. struct task

33、_struct *p;33.34. p = kthread_create(zqfd_thread, null,"%sn,"zqfd");35.36. if ( p ) 37. zqf_thread = p;38. wake_up_process(zqf_thread); / actually start it up39. return(o);40. 41.42. return(-1);43. 44.45. static void _exit zqffini(void)46. 47. kthread_stop(zqf_thread);48. 49.50. modul

34、e_init(zqfinit);51. module_exit(zqffini)52.53. makefile obj-m += zqfthread.o54. making #> make -c /usr/src/kernels/2.6.32-71.el6.x86_64/ m='pwd' modules2、用crash工具分析vmcore文件用crash命令分析vmcore的命令行格式如下所示。用crash打開vmcore后，主要是用dmesg及bt命令打印出問題的執(zhí)行路徑的call trace,用dis反匯編出代碼，最終確認(rèn)call trace 對應(yīng)的c源碼中的位置，再

35、進(jìn)行邏輯分析。#>crash /usr/lib/debug/lib/modules/2.6.18-128.el5.x86_64/vmlinux /boot/system.map-2.6.18-128. el5.x86_64 ./vmcore6、使用kprobe來觀察內(nèi)核函數(shù)的執(zhí)行實(shí)例kprobe是systemtap對內(nèi)核函數(shù)進(jìn)行probing的功能在內(nèi)核屮的實(shí)現(xiàn)，由于內(nèi)核中提供了 正式的api來使用kprobe,所以對很多內(nèi)核程序員來說，也許直接使用kprobe比使用 systemtap更方便。內(nèi)核屮提供了三種類型的kprobe處理函數(shù)，分別是jprobe, kprobe, kretpr

36、obe,下面的代碼用這三個(gè)probe觀察在tcp/ip的arp_process函數(shù)執(zhí)行中對 ipoute_input()調(diào)用的返回結(jié)果。這個(gè)代碼還展示了在同一個(gè)函數(shù)probe的entry handler和ret handler之間共享參數(shù)的方法。代碼如下：1. arpjdrobe.c /*2. * arp_probe.c, by qianfeng zhang (frzhang)3. 74.5. #include6 #include7. #include8. #include9. #include10. #include11. #include12. #include13.14. module_

37、author("frzhang");15. module_description("a module to track the call results of ipoutenput() insid e arp_process using jprobe and kretprobe'1);16. modulejjcense(”gpl”)；17.18. static int j_arp_process(struct sk_buff *skb)19. 20. struct net_device *dev = skb->dev;21 struct in_dev

38、ice "in_dev;22. int no_addr5 rpf;23.24. in_dev = in_dev_get(dev);25. no_addr = (in_dev->ifa_list = null );26. rpf = in_dev_rpfilter(in_dev);27. in_devjdut(in_dev);28. printk(hnarp_process() is called with interface device %s, in_dev(no_ addr=%d,rpf=% d) n： dev->name, no_addr, rpf);29. jpr

39、obe_return();30. return(o);31. ；32.33 static int j_fib_validate_source(_be32 src, _be32 dst, u8 tos, int oif,34. struct net_device *dev, _be32 *spec_dst5 u32 *itag, u32 mark)35.36. 37. printk("fib_validate_source() is called with dst=0x%x, oif=%d n”，dst, oif);38. jprobe_return();39. return(o);4

40、0. ;41.42. static struct jprobe myjpl = 43. .entry = j_arp_process,44. kp.symbol_name = ,arp_process,'45. ；46.47. static struct jprobe myjp2 = 48. .entry = jib_validate_source,49. ,kp.symbol_name = "fib_validate_source"50. ；51.52. static int entry_handler(struct kretprobejnstance *ri,

41、struct pt_regs *regs)53. 54. printk("calling: %s()n", ri->rp->kp.symbol_name);55. return(o);56. ；57.58. static int return_handler(struct kretprobe_instance *ri, struct pt_regs *regs)59. 60. int eax;61.62. eax = regs->ax & oxffff;63. printk("returning: %s() with a return v

42、alue: ox%儀(64bit) 0x%x(32bit)n", ri->rp->kp.sy mbol_name, regs->ax, eax);64.65. return(o);66. ；67.68. static int fib_lookup_entry_handler(struct kretprobejnstanee *ri, struct pt_regs *regs)69. 70. struct fib_result *resp;71.72. resp = (struct fib_result *) regs->dx;73. printk("

43、calling: %s()n", ri->rp->kp.symbol_name);74. *(struct fib_result *)ri->data) = resp;75.76. return(o);77. ；78.79. static int fibjookup_return_handler(struct kretprobejnstance *ri, struct pt_regs *regs)80. 81. struct fib_result *resp;82. int eax;83.84. eax = regs->ax & oxffff;85.

44、resp = *(struct fib_result *) ri->data);86. printkc'returning: fib_lookup() with a return value: 0x%lx(64bit) 0x%x(32bit), result->t ype: %dn", regs->ax, eax, resp->type);87.88. return(o);89. 90.91. static struct kretprobe my _rp1 = 92. .handler = return_handler,93. entry_handle

45、r = entry_handler,94. .kp.symbol_name = hip_route_input_slowh95. ;96.97. static struct kretprobe my ,rp2 = 98. handler = return_handler,99. .entry_handler = entry_handler,100. .kp.symbol_name = ,fib_validate_sourceh101. ;102.103 static struct kretprobe my_rp3 = 104. .handler = fib_lookup_return_hand

46、ler,105entry_handler = fib_lookup_entry_handler,106. .kp.symbol name = ”fibookupm,107. data_size = sizeof(struct fib_result *)108. ;109.110. static int _init init_myprobe(void)111. 112. int ret;113.114. printk(mrtn_unicast is %dnh, rtn_unicast);115. if (ret = registerjprobe(&myjp1) < 0) 116. printk(hregisterjprobe %s failed