紅帽Linux故障定位技術(shù)詳解與實例
紅帽Linux故障定位技術(shù)詳解與實例是本文要介紹的內(nèi)容，主要是來了解并學習紅帽linux中故障定位技術(shù)的學習，故障定位技術(shù)分為在線故障定位和離線故障定位，一起來看詳解。
1、故障定位(Debugging)場景分類
為便于描述問題，將Linux上各種軟件故障定位的情形分成兩類
（1）在線故障故障定位
在線故障定位(online-debugging)就是在故障發(fā)生時, 故障所處的操作系統(tǒng)環(huán)境仍然可以訪問，故障處理人員可通過console, ssh等方式登錄到操作系統(tǒng)上，在shell上執(zhí)行各種操作命令或測試程序的方式對故障環(huán)境進行觀察，分析，測試，以定位出故障發(fā)生的原因
（2）離線故障定位
離線故障定位(offline-debugging)就是在故障發(fā)生時，故障所處的操作系統(tǒng)環(huán)境已經(jīng)無法正常訪問，但故障發(fā)生時系統(tǒng)的全部或部分狀態(tài)已經(jīng)被系統(tǒng)本身所固有或事先設(shè)定的方式收集起來，故障處理人員可通過對收集到的故障定位狀態(tài)信息進行分析，定位出故障發(fā)生的原因
2、應用進程故障情形及處理
應用進程的故障一般不會影響操作系統(tǒng)運行環(huán)境的正常使用（如果應用代碼的bug導致了內(nèi)核的crash或hang,則屬于內(nèi)核存在漏洞)，所以可采用在線故障定位的方法，靈活的進行分析. 應用代碼故障的情形有如下幾種:
（1）進程異常終止
很多用戶認為進程異常終止情況無從分析，但實際上進程異常終止情況都是有跡可尋的. 所有的進程異常終止行為，都是通過內(nèi)核發(fā)信號給特定進程或進程組實現(xiàn)的. 可分成幾個類型進行描述:
- SIGKILL. SIGKILL最特殊，因為該信號不可被捕獲，同時SIGKILL不會導致被終止的進程產(chǎn)生core文件, 但如果真正的是由內(nèi)核中發(fā)出的SIGKILL,則內(nèi)核一定會在dmesg中記錄下信息. 另外在內(nèi)核中使用SIGKILL的地方***，如oom_kill_process()中, 所以通過dmesg記錄并且分析內(nèi)核中使用SIGKILL的代碼，并不難分析原因
- SIGQUIT, SIGILL, SIGABRT, SIGBUS, SIGFPE, SIGSEGV. 這幾個信號在保留情況下會終止進程并會產(chǎn)生core文件, 用戶根據(jù)core中的stack trace信息，能直接定位出導致終止信號的代碼位置. 另外, SIGQUIT，SIGABRT一般是由用戶代碼自己使用的，好的代碼一般會記錄日志. SIGILL, SIGBUS, SIGFPE, SIGSEGV, 都是由內(nèi)核中產(chǎn)生的，搜索內(nèi)核源碼，不難列出內(nèi)核中使用這幾個信號的地方, 如SIGILL 是非法指令，可能是浮點運算產(chǎn)生的代碼被corrupted或文本區(qū)域的物理內(nèi)存corruption; SIGBUS多由MCE故障定位導致; SIGSEGV多由應用代碼的指針變量被corrupted導致. 對于應用的heap或stack的內(nèi)存被corrupted, 可用valgrind工具對應用進行profile, 通常能直接發(fā)現(xiàn)導致corruption的代碼
- SIGINT, SIGPIPE, SIGALRM, SIGTERM. 這幾個信號在保留情況下終止進程但不會產(chǎn)生core文件. 對這幾個信號，建議用戶一定要定義一個handler,以記錄產(chǎn)生問題的上下文. 比較容易忽略的是SIGPIPE, 很多用戶程序在使用select()或poll()時只監(jiān)聽read/write描述符，不監(jiān)聽exception描述符，在對方TCP已經(jīng)關(guān)閉的情況下，仍然向socket中寫入，導致SIGPIPE.
- 對于惡意的代嗎產(chǎn)生的進程終止行為，如合作的一些進程中，A向B發(fā)SIGKILL, 而沒做日志記錄，或者B直接判斷某條件而調(diào)用exit(), 也沒有做日志記錄.在應用代碼量很大的情況下，通過分析代碼故障定位這種情形也許很難. SystemTap提供了解決這個問題的一個比較好的方法，就是寫用戶層的probes, 追蹤進程對signal(), exit() 等系統(tǒng)調(diào)用的使用
（2）進程阻塞，應用無法正常推進
這種情況，對于單個被阻塞的進程而言，屬于正常狀態(tài)， 但對于包含多個進程的應用整體而言，屬于異常. 應用無法推進，說明其中某一個進程推進的因素出現(xiàn)了問題，導致其他依賴于它的進程也要等待. 分析這種情形需要分析清楚進程或事件之間的依賴關(guān)系，及數(shù)據(jù)的處理流. 首先要用gdb -p 的back trace功能查出各進程阻塞的執(zhí)行路徑, 以確定每個進程所處在的狀態(tài)機的位置.
通常而言，如果只考慮各個進程的狀態(tài)，則進程之間可能形成了一種互相依賴的環(huán)形關(guān)系，如(P1發(fā)請求=>P2處理=>P2發(fā)反應=>P1再請求=>P2處理=>P2再發(fā)反應), 但應用對workload, 一般是按一個個的transaction 或 session的方式進行處理的,每個transaction都有起點和終點, 我們需要用strace, tcpdump 等工具以及應用的執(zhí)行日志進行觀察，分析出當前正被處理的transaction所被阻滯的位置，從而找出全部狀態(tài)機被阻塞的原因. 導致這種狀態(tài)機停止運轉(zhuǎn)的原因有多個：如和應用通信的遠端出現(xiàn)了問題，后端數(shù)據(jù)庫/目錄等出現(xiàn)了問題，應用的某個進程或線程處于非正常的blocking位置或直接終止，不再正常工作.
（3）用戶進程形成死鎖
用戶進程形成死鎖，如果沒有內(nèi)存上的故障定位，則完全是應用自身的邏輯問題. 死鎖的進程或線程之間由于鎖的互相占有形成了環(huán)路。 這種情況發(fā)生時，用gdb -p 的back trace的功能能直接確定死鎖的進程全部阻塞在futex()等和鎖相關(guān)的系統(tǒng)調(diào)用上, 這些調(diào)用futex()的路徑可能是mutex, semaphore, conditional variable 等鎖函數(shù). 通過分析call trace 的代碼，能直接確定各進程在執(zhí)行到該位置時，可能已經(jīng)持有的全部鎖, 根據(jù)這個修改程序的代碼，消除死鎖環(huán)路，就可解決問題.
注意，內(nèi)存故障也可導致假的死鎖的，如物理內(nèi)存故障可直接導致鎖變量的值為-1， 所以使用該鎖的進程都會阻塞. 如果是代碼的bug導致的內(nèi)存corruption,可用valgrind工具檢查程序來發(fā)現(xiàn). 但如果是物理內(nèi)存的故障定位導致的corruption, 則需要硬件的支持，對于高端的PC, 如MCE功能的機器，當物理內(nèi)存故障定位時能直接產(chǎn)生異常或報告, 但對于低端PC服務器，除了運行memtest工具進行檢測外，沒有其他方法
（4）進程長期處于 'D' (UnInterruptible)狀態(tài)沒法退出
這種多是由內(nèi)核中的故障引起的. 內(nèi)核在很多執(zhí)行路徑中會將進程至于'D'的狀態(tài)，以確保關(guān)鍵的執(zhí)行路徑不被外部的信號中斷, 導致不必要的內(nèi)核中數(shù)據(jù)結(jié)構(gòu)狀態(tài)的不一致性. 但一般而言，進程處于 'D' 狀態(tài)的時間不會太久, 因為狀態(tài)結(jié)束的條件(如timer觸發(fā)，
IO操作完成等)很快會將進程喚醒. 當進程長期處于 'D',關(guān)鍵是要找出其阻塞的代碼位置， 用 sysrq 的t鍵功能可直接打印出系統(tǒng)中全部睡眠進程的內(nèi)核執(zhí)行堆棧，如 echo 't' > /proc/sysrq-trigger, 其中包括出現(xiàn) 'D'狀態(tài)的進程的內(nèi)核態(tài)堆棧. 找出代碼位置后，一般可直接分析出 'D' 狀態(tài)不能退出的原因, 如IO read操作因硬件或nfs故障而不能完成.
有可能導致 'D' 狀態(tài)的原因比較復雜，如‘D’的退出依賴于某變量的值，而該變量的值因某種原因被***corrupted掉了.
#p#
3、內(nèi)核故障情形及處理
（1）內(nèi)核panic
panic是內(nèi)核最直接的故障定位報告，發(fā)生panic時，內(nèi)核已經(jīng)認為故障定位已經(jīng)導致操作系統(tǒng)不再具備正常運行的條件了. 當發(fā)生panic時，Linux會將所有CPU的中斷和進程調(diào)度功能都關(guān)掉，所以這時系統(tǒng)是沒有任何反應的，如果用戶啟動的是圖形界面，則在屏幕上也看不到任何關(guān)于panic的信息.
我們通常遇到的，機器沒反應，ping不通的情況，絕大部分都是panic. Panic發(fā)生時，內(nèi)核直接在console上打印導致panic的代碼位置的調(diào)用堆棧, 傳統(tǒng)的用戶用串口連接到機器上來收集console上的打印信息, 但串口這種方式，顯然用起來不方便, 現(xiàn)在的Linux, 如RHEL5,RHEL6， 都采用kdump的方法來收集panic時的信息. 在配置好kdump的情況下，panic時系統(tǒng)會用kexec加載并切換到一個新的內(nèi)核上(放置在預先分配的內(nèi)存位置)，并用磁盤或網(wǎng)絡(luò)等將系統(tǒng)的全部或部分內(nèi)存數(shù)據(jù)保存起來.
用kdump收集到panic的數(shù)據(jù)后，用戶用crash工具就能直接查看導致panic的代碼路徑.
panic一般是很直觀的，panic的堆棧信息能直接反映出導致bug的原因，如MCE故障，NMI故障, 數(shù)據(jù)結(jié)構(gòu)分配失敗等. 但有時panic是因為內(nèi)核主動發(fā)現(xiàn)了關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)不一致性，這種不一致性是什么時候，什么代碼導致的，并不清楚，可能還需要多次測試用SystemTap這樣的工具進行捕捉
（2）多處理機環(huán)境內(nèi)核執(zhí)行路徑產(chǎn)生的死鎖
內(nèi)核死鎖和panic不一樣，產(chǎn)生死鎖時，內(nèi)核并不主動的使自己處于掛起狀態(tài). 但內(nèi)核死鎖發(fā)生時，兩個以上的CPU的執(zhí)行路徑在內(nèi)核態(tài)不能推進了，處于互相阻塞狀態(tài), 而且是100%的占用CPU(用的spin-lock)，直接或間接的導致全部CPU上的進程無法調(diào)度. 內(nèi)核死鎖又分兩種情況:
- 涉及到中斷上下文的死鎖. 這種情況的死鎖，最少一個CPU上的中斷被屏蔽了.系統(tǒng)可能沒法響應ping請求. 由于有一個CPU已經(jīng)沒法響應中斷，其上的local APIC定時中斷沒法工作，可以用NMI Watchdog的方法來檢測出來(檢查local APIC handler維護的計數(shù)器變量)，NMI Watchdog可以在其處理程序中調(diào)用panic(), 用戶就可以用kdump收集內(nèi)存信息，從而分析各死鎖CPU上的調(diào)用堆棧，查處導致死鎖的邏輯原因.
- 不涉及中斷上下文的死鎖. 這種情況的死鎖，各CPU上的中斷都是正常的，系統(tǒng)能對ping請求作出反應，這時NMI Watchdog無法被觸發(fā). 在 2.6.16之前的內(nèi)核中,并沒有一種很好的方法來處理這種情形. 在RHEL5, RHEL6 內(nèi)核中， 每個CPU上提供了一個watchdog內(nèi)核線程，在死鎖出現(xiàn)的情況下，死鎖CPU上的watchdog內(nèi)核線程沒法被調(diào)度(即使它是***優(yōu)先級的實時進程),它就沒法update相應的counter變量，各CPU的NMI Watchdog中斷會周期性的檢查其CPU對應的counter, 發(fā)現(xiàn)沒有updated, 會調(diào)用panic()，用戶就可用kdump收集內(nèi)存信息，分析各死鎖CPU上的調(diào)用堆棧，查處導致死鎖的邏輯原因.
（3）內(nèi)核的oops或warning
oops 和warning和panic類似的地方是，他們都是因內(nèi)核發(fā)現(xiàn)了不一致而主動報告的異常. 但oops和warning導致的問題嚴重程度要比panic輕很多，以致于內(nèi)核處理該問題時不需要使系統(tǒng)掛起. 產(chǎn)生oops和warning, 內(nèi)核通常已經(jīng)在dmesg中記錄了相當?shù)男畔ⅲ貏e是oops, 至少會打印出現(xiàn)故障的地方的call trace. Oops也可轉(zhuǎn)換成panic/kdump來進行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)的counter值不對, 而segment fault 和counter值的變化還有更深層次的原因，通常并不能從內(nèi)核dmesg的信息中看出來，解決這種問題的是要用SystemTap進行probe, 如發(fā)現(xiàn)某counter的值不對，就用SystemTap做一個probe來記錄所有代碼對該counter的訪問, 然后再進行分析.
定位oops和warning會比定位應用程序的內(nèi)存訪問故障定位困難很多，因為在內(nèi)核并不能象用valgrind去trace應用程序一樣跟蹤數(shù)據(jù)結(jié)構(gòu)的分配和使用情況.
2、其他(硬件相關(guān))故障
機器自動重啟是一種常見的故障情形，一般是由硬件如物理內(nèi)存故障引起的，軟件的故障只會導致死鎖或panic, 內(nèi)核中幾乎沒有代碼在發(fā)現(xiàn)問題的情況下去reboot機器. 在/proc/sys/kernel目錄下有個參數(shù)“panic”, 其值如果設(shè)置為非0，則在panic發(fā)生若干秒后，內(nèi)核會重啟機器. 現(xiàn)在高端的PC服務器，都在努力用軟件來處理物理內(nèi)存故障，如MCA的 “HWPoison”方法會將故障的物理頁隔離起來，Kill掉故障頁所在的進程就可以了，RHEL6現(xiàn)在已經(jīng)支持 “HWPoison”. 那些不具備MCA能力的機器，物理內(nèi)存故障時，不會產(chǎn)生MCE異常，直接由硬件機制reboot機器
4、RHEL6 上的Debugging技術(shù)介紹
（1）Kdump故障定位收集和crash分析
kdump就是用來在內(nèi)核panic的情況下收集系統(tǒng)內(nèi)存信息的, 用戶也可在online情況下用sysrq的'c'鍵觸發(fā). Kdump 采用沒有污染的內(nèi)核來執(zhí)行dump工作，所以其比以前的diskdump, lkcd方法更可靠. 使用kdump，用戶可選擇將數(shù)據(jù)dump到本地盤或網(wǎng)絡(luò)上，也可通過定義makedumpfile的參數(shù)過濾要收集的內(nèi)存信息，已減少kdump所需要的停機時間
Crash就是對kdump的信息進行分析的工具.其實際就是gdb的一個wrapper. 使用crash時，***安裝kernel-debuginfo包，這樣能解析kdump收集的內(nèi)核數(shù)據(jù)的符號信息. 用crash來定位問題的能力，完全取決于用戶對內(nèi)核代碼的理解和分析能力
參考 “#>man kdump.conf”, “#>man crash”, “#>man makedumpfile”學習怎樣使用kdump和crash. 訪問 http://ftp.redhat.com可下載debuginfo文件
（2）用systemTap定位bug
systemtap 屬于probe類的定位工具,它能對內(nèi)核或用戶代碼的指定位置進行probe, 當執(zhí)行到指定位置或訪問指定位置的數(shù)據(jù)時，用戶定義的probe函數(shù)自動執(zhí)行，可打印出該位置的調(diào)用堆棧，參數(shù)值，變量值等信息. systemtap選擇進行probe的位置很靈活，這是systemtap的強大功能所在. Systemtap的probe點可包括如下幾個方面:
- 內(nèi)核中全部系統(tǒng)調(diào)用，內(nèi)核及模塊中全部函數(shù)的入口或出口點
- 自定義的定時器probe點
- 內(nèi)核中任意指定的代碼或數(shù)據(jù)訪問位置
- 特定用戶進程中任意制定的代碼或數(shù)據(jù)訪問位置
- 各個功能子系統(tǒng)預先設(shè)置的若干probe點，如tcp,udp,nfs,signal各子系統(tǒng)都預先設(shè)置了很多探測點
systemTap的腳本用stap腳本語言來編寫，腳本代碼中調(diào)用stap提供的API進行統(tǒng)計，打印數(shù)據(jù)等工作，關(guān)于stap語言提供的API函數(shù)，參考 “#> man stapfuncs”. 關(guān)于systemTap的功能和使用可參考 “#> man stap”, “#> man stapprobes”
（3）ftrace
ftrace 是linux內(nèi)核中利用tracepoints基礎(chǔ)設(shè)施實現(xiàn)的事件追蹤機制，它的作用在于能比較清楚的給出在一定時間內(nèi)系統(tǒng)或進程所執(zhí)行的活動，如函數(shù)調(diào)用路徑，進程切換流等. Ftrace可用于觀察系統(tǒng)各部分的latency,以便進行實時應用的優(yōu)化； 它也可以通過記錄一段時間內(nèi)的內(nèi)核活動來幫助故障定位. 如用以下方法可trace某個進程在一端時間的函數(shù)調(diào)用情況
- #> echo “function” > /sys/kernel/debug/tracing/current_tracer
- #> echo “xxx” > /sys/kernel/debug/tracing/set_ftrace_pid
- #> echo 1 > /sys/kernel/debug/tracing/tracing_enabled
除tracing函數(shù)調(diào)用外，ftrace還可tracing系統(tǒng)的進程切換，喚醒，塊設(shè)備訪問，內(nèi)核數(shù)據(jù)結(jié)構(gòu)分配等活動. 注意，tracing和profile是不同的，tracing記錄的是一段時間內(nèi)的全部活動，而不是統(tǒng)計信息，用戶可以通過/sys/kernel/debug/tracing下的buffer_size_kb設(shè)置緩沖區(qū)的大小, 以記錄更長時間的數(shù)據(jù).
關(guān)于ftrace的具體使用可參考內(nèi)核源碼Documenation/trace下的內(nèi)容
（4）oprofile 和 perf
oprofile和perf都是對系統(tǒng)進行profile(抽樣，統(tǒng)計)的工具，它們主要用來解決系統(tǒng)和應用的性能問題. perf功能更強大，更全面,同時perf的用戶空間工具和內(nèi)核源碼一起維護和發(fā)布，讓用戶能及時的享受perf內(nèi)核新增加的特征. Perf 是在RHEL6中才有，RHEL5中沒有Perf. Oprofile和perf 都使用現(xiàn)代CPU中具有的硬件計數(shù)器進行統(tǒng)計工作，但perf還可以使用內(nèi)核中定義的 “software counter”及 “trace points”, 所以能做更多的工作. Oprofile的抽樣工作利用 CPU的NMI中斷來進行，而perf既可以利用NMI中斷也可利用硬件計數(shù)器提供的周期性中斷. 用戶能很容易用perf來oprofile一個進程或系統(tǒng)的執(zhí)行時間分布，如
- #> perf top -f 1000 -p
還可以利用系統(tǒng)定義的 “software counter”和各子系統(tǒng)的 “trace points” 對子系統(tǒng)進行分析, 如
- #>perf stat -a -e kmem:mm_page_alloc -e kmem:mm_page_free_direct -e kmem:mm_pagevec_free sleep 6
能統(tǒng)計6秒內(nèi)kmem子系統(tǒng)的活動 (這一點實際是利用ftrace提供的tracepoints來實現(xiàn))
我認為有了perf, 用戶就沒必要使用oprofile了
#p#
5、用kdump工具內(nèi)核故障定位實例
A) 部署Kdump
部署 kdump 收集故障信息的步驟如下:
（1）設(shè)置好相關(guān)的內(nèi)核啟動參數(shù)
在 /boot/grub/menu.lst 中加入如下內(nèi)容
- crashkernel=128M@16M nmi_watchdog=1
其中crashkernel參數(shù)是用來為kdump的內(nèi)核預留內(nèi)存的; nmi_watchdog=1 是用來激活NMI中斷的, 我們在未確定故障是否關(guān)閉了中斷的情況下, 需要部署NMI watchdog才能確保觸發(fā)panic. 重啟系統(tǒng)確保設(shè)置生效
（2）設(shè)置好相關(guān)的sysctl內(nèi)核參數(shù)
在/etc/sysctl.conf 中***加入一行
- kernel.softlookup_panic = 1
該設(shè)置確保softlock發(fā)生時會調(diào)用panic, 從而觸發(fā)kdump行為執(zhí)行 #>sysctl -p 確保設(shè)置生效
（3）配置 /etc/kdump.conf
在 /etc/kdump.conf 中加入如下幾行內(nèi)容
- ext3 /dev/sdb1
- core-collector makedumpfile -c –message-level 7 -d 31 -i /mnt/vmcoreinfo
- path /var/crash
- 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è)務太長時間時很重要. vmcoreinfo 文件放置在 /dev/sdb1 分區(qū)的 / 目錄下, 需要使用如下命令產(chǎn)生:
#>makedumpfile -g //vmcoreinfo -x /usr/lib/debug/lib/modules/2.6.18-128.el5.x86_64/vmlinux
“vmlinux” 文件是由kernel-debuginfo 包提供的，在運行makedumpfile 之前需要安裝相應內(nèi)核的 kernel-debuginfo 和 kernel-debuginfo-common 兩個包，該兩個包需從 http://ftp.redhat.com 下載. “default reboot” 用來告訴kdump, 收集完dump信息后重啟系統(tǒng)
(4)激活kdump
運行 #>service kdump start 命令，你會看到，在成功完成的情況下會在/boot/目錄下生成一個initrd-2.6.18-128.el5.x86_64kdump.img 文件，該文件就是kdump加載的內(nèi)核的 initrd文件，收集dump信息的工作就是在該initrd的啟動環(huán)境下進行的. 查看/etc/init.d/kdump腳本的代碼，你可看到其中會調(diào)用mkdumprd命令創(chuàng)建用于dump的initrd文件
1、測試Kdump部署的有效性
為了測試kdump部署的有效性，本人寫了如下一個內(nèi)核模塊，通過insmod 加載該內(nèi)核模塊， 就能產(chǎn)生一個內(nèi)核線程，在10秒左右后，占據(jù)100%的CPU，在20秒左右后觸發(fā)kdump. 系統(tǒng)重啟后，檢查/oracle分區(qū)/var/crash 目錄下的內(nèi)容，就能確認vmcore文件是否生成.
- Zqfthread.c #include
- #include
- #include
- #include
- #include
- #include
- MODULE_AUTHOR("frzhang@redhat.com");
- MODULE_DESCRIPTION("A module to test ....");
- MODULE_LICENSE("GPL");
- static struct task_struct *zqf_thread;
- static int zqfd_thread(void *data);
- static int zqfd_thread(void *data)
- {
- int i=0;
- while (!kthread_should_stop()) {
- i++;
- if ( i < 10 ) {
- msleep_interruptible(1000);
- printk("%d seconds\n", i);
- }
- if ( i == 1000 ) // Running in the kernel
- i = 11 ;
- }
- return 0;
- }
- static int __init zqfinit(void)
- {
- struct task_struct *p;
- p = kthread_create(zqfd_thread, NULL,"%s","zqfd");
- if ( p ) {
- zqf_thread = p;
- wake_up_process(zqf_thread); // actually start it up
- return(0);
- }
- return(-1);
- }
- static void __exit zqffini(void)
- {
- kthread_stop(zqf_thread);
- }
- module_init(zqfinit);
- module_exit(zqffini)
- Makefile obj-m += zqfthread.o
- Making #> make -C /usr/src/kernels/2.6.32-71.el6.x86_64/ M=`pwd` modules
2、用crash 工具分析vmcore 文件
用crash 命令分析vmcore 的命令行格式如下所示. 用crash打開vmcore后，主要是用dmesg及 bt 命令打印出問題的執(zhí)行路徑的call trace, 用dis 反匯編出代碼，最終確認call trace對應的C源碼中的位置，再進行邏輯分析.
- #>crash /usr/lib/debug/lib/modules/2.6.18-128.el5.x86_64/vmlinux /boot/System.map-2.6.18-128.el5.x86_64 ./vmcore
#p#
6、使用kprobe來觀察內(nèi)核函數(shù)的執(zhí)行實例
kprobe是SystemTap對內(nèi)核函數(shù)進行probing的功能在內(nèi)核中的實現(xiàn)，由于內(nèi)核中提供了正式的API來使用kprobe,所以對很多內(nèi)核程序員來說，也許直接使用kprobe比使用SystemTap更方便. 內(nèi)核中提供了三種類型的kprobe處理函數(shù)，分別是jprobe, kprobe, kretprobe, 下面的代碼用這三個probe觀察在TCP/IP的arp_process函數(shù)執(zhí)行中對ip_route_input()調(diào)用的返回結(jié)果.這個代碼還展示了在同一個函數(shù)probe的Entry handler和Ret handler之間共享參數(shù)的方法. 代碼如下:
- arp_probe.c /*
- * arp_probe.c, by Qianfeng Zhang (frzhang@redhat.com)
- */
- #include
- #include
- #include
- #include
- #include
- #include
- #include
- #include
- MODULE_AUTHOR("frzhang@redhat.com");
- MODULE_DESCRIPTION("A module to track the call results of ip_route_input() inside arp_process using jprobe and kretprobe");
- MODULE_LICENSE("GPL");
- static int j_arp_process(struct sk_buff *skb)
- {
- struct net_device *dev = skb->dev;
- struct in_device *in_dev;
- int no_addr, rpf;
- in_dev = in_dev_get(dev);
- no_addr = ( in_dev->ifa_list == NULL );
- rpf = IN_DEV_RPFILTER(in_dev);
- in_dev_put(in_dev);
- printk("\narp_process() is called with interface device %s, in_dev(no_addr=%d,rpf=%d) \n", dev->name, no_addr, rpf);
- jprobe_return();
- return(0);
- };
- static int j_fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
- struct net_device *dev, __be32 *spec_dst, u32 *itag, u32 mark)
- {
- printk("fib_validate_source() is called with dst=0x%x, oif=%d \n", dst, oif);
- jprobe_return();
- return(0);
- };
- static struct jprobe my_jp1 = {
- .entry = j_arp_process,
- .kp.symbol_name = "arp_process"
- };
- static struct jprobe my_jp2 = {
- .entry = j_fib_validate_source,
- .kp.symbol_name = "fib_validate_source"
- };
- static int entry_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
- {
- printk("Calling: %s()\n", ri->rp->kp.symbol_name);
- return(0);
- };
- static int return_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
- {
- int eax;
- eax = regs->ax & 0xffff ;
- printk("Returning: %s() with a return value: 0x%lx(64bit) 0x%x(32bit)\n", ri->rp->kp.symbol_name, regs->ax, eax);
- return(0);
- };
- static int fib_lookup_entry_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
- {
- struct fib_result *resp;
- resp = (struct fib_result *) regs->dx;
- printk("Calling: %s()\n", ri->rp->kp.symbol_name);
- *((struct fib_result **)ri->data) = resp;
- return(0);
- };
- static int fib_lookup_return_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
- {
- struct fib_result *resp;
- int eax;
- eax = regs->ax & 0xffff ;
- resp = *((struct fib_result **) ri->data);
- printk("Returning: fib_lookup() with a return value: 0x%lx(64bit) 0x%x(32bit), result->type: %d\n", regs->ax, eax, resp->type);
- return(0);
- }
- static struct kretprobe my_rp1 = {
- .handler = return_handler,
- .entry_handler = entry_handler,
- .kp.symbol_name = "ip_route_input_slow"
- };
- static struct kretprobe my_rp2 = {
- .handler = return_handler,
- .entry_handler = entry_handler,
- .kp.symbol_name = "fib_validate_source"
- };
- static struct kretprobe my_rp3 = {
- .handler = fib_lookup_return_handler,
- .entry_handler = fib_lookup_entry_handler,
- .kp.symbol_name = "fib_lookup",
- .data_size = sizeof(struct fib_result *)
- };
- static int __init init_myprobe(void)
- {
- int ret;
- printk("RTN_UNICAST is %d\n", RTN_UNICAST);
- if ( (ret = register_jprobe(&my_jp1)) < 0) {
- printk("register_jprobe %s failed, returned %d\n", my_jp1.kp.symbol_name, ret);
- return(-1);
- }
- if ( (ret = register_jprobe(&my_jp2)) < 0) {
- printk("register_jprobe %s failed, returned %d\n", my_jp2.kp.symbol_name, ret);
- return(-1);
- }
- if ( (ret = register_kretprobe(&my_rp1)) < 0 ) {
- printk("register_kretprobe %s failed, returned %d\n", my_rp1.kp.symbol_name, ret);
- unregister_jprobe(&my_jp1);
- unregister_jprobe(&my_jp2);
- return(-1);
- }
- if ( (ret = register_kretprobe(&my_rp2)) < 0 ) {
- printk("register_kretprobe %s failed, returned %d\n", my_rp2.kp.symbol_name, ret);
- unregister_jprobe(&my_jp1);
- unregister_jprobe(&my_jp2);
- unregister_kretprobe(&my_rp1);
- return(-1);
- }
- if ( (ret = register_kretprobe(&my_rp3)) < 0 ) {
- printk("register_kretprobe %s failed, returned %d\n", my_rp3.kp.symbol_name, ret);
- unregister_jprobe(&my_jp1);
- unregister_jprobe(&my_jp2);
- unregister_kretprobe(&my_rp1);
- unregister_kretprobe(&my_rp2);
- return(-1);
- }
- return 0;
- }
- static void __exit rel_myprobe(void)
- {
- unregister_jprobe(&my_jp1);
- unregister_jprobe(&my_jp2);
- unregister_kretprobe(&my_rp1);
- unregister_kretprobe(&my_rp2);
- unregister_kretprobe(&my_rp3);
- }
- module_init(init_myprobe);
- module_exit(rel_myprobe);
- Makefile obj-m += arp_probe.o
- Making #> make -C /usr/src/kernels/2.6.32-71.el6.x86_64/ M=`pwd` modules
Linux故障定位技術(shù)詳解與實例的內(nèi)容介紹完了，希望通過本文紅帽Linux故障定位技術(shù)的學習能對你有所幫助！
原文地址：http://beareyes.com.cn/2/lib/201109/27/20110927182_0.htm
