1 功能說明
strace 命令是一種強大的工具, 能夠顯示任何由用戶空間程式發出的系統調用. strace 顯示這些調用的參數並返回符號形式的值. strace 從內核接收信息, 而且無需以任何特別的方式來構建內核. strace 的每一行輸出包括系統調用名稱, 然後是參數和返回值.
下面記錄幾個常用option:
-f -F選項告訴strace同時跟蹤fork和vfork出來的進程
-o xxx.txt 輸出到某個文檔.
-e execve 只記錄 execve 這類系統調用.
2 詳細用法
usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file]
[-p pid] ... [-s strsize] [-u username] [-E var=val] ...
[command [arg ...]]
or: strace -c [-e expr] ... [-O overhead] [-S sortby] [-E var=val] ...
[command [arg ...]]
-c -- count time, calls, and errors for each syscall and report summary
-f -- follow forks, -ff -- with output into separate files
-F -- attempt to follow vforks, -h -- print help message
-i -- print instruction pointer at time of syscall
-q -- suppress messages about attaching, detaching, etc.
-r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs
-T -- print time spent in each syscall, -V -- print version
-v -- verbose mode: print unabbreviated argv, stat, termio[s], etc. args
-x -- print non-ascii strings in hex, -xx -- print all strings in hex
-a column -- alignment COLUMN for printing syscall results (default 40)
-e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]...
options: trace, abbrev, verbose, raw, signal, read, or write
-o file -- send trace output to FILE instead of stderr
-O overhead -- set overhead for tracing syscalls to OVERHEAD usecs
-p pid -- trace process with process id PID, may be repeated
-s strsize -- limit length of print strings to STRSIZE chars (default 32)
-S sortby -- sort syscall counts by: time, calls, name, nothing (default time)
-u username -- run command as username handling setuid and/or setgid
-E var=val -- put var=val in the environment for command
-E var -- remove var from the environment for command
3 參數說明
-c 統計每一系統調用的所執行的時間,次數和出錯的次數等.
-d 輸出strace關於標準錯誤的調試信息.
-f 跟蹤由fork調用所產生的子進程.
-ff 如果提供-o filename,則所有進程的跟蹤結果輸出到相應的filename.pid中,pid是各進程的進程號.
-F 嘗試跟蹤vfork調用.在-f時,vfork不被跟蹤.
-h 輸出簡要的幫助信息.
-i 輸出系統調用的入口指針.
-q 禁止輸出關於脫離的消息.
-r 打印出相對時間關於每一個系統調用.
-t 在輸出中的每一行前加上時間信息.
-tt 在輸出中的每一行前加上時間信息,微秒級.
-ttt 微秒級輸出,以秒了表示時間.
-T 顯示每一調用所耗的時間.
-v 輸出所有的系統調用.一些調用關於環境變量,狀態,輸入輸出等調用由於使用頻繁,默認不輸出.
-V 輸出strace的版本信息.
-x 以十六進制形式輸出非標準字符串.
-xx 所有字符串以十六進制形式輸出.
-a column 設置返回值的輸出位置.默認 爲40.
-e expr 指定一個表達式,用來控制如何跟蹤.格式如下:
[qualifier=][!]value1[,value2]...
qualifier只能是 trace,abbrev,verbose,raw,signal,read,write其中之一.value是用來限定的符號或數字.默認的 qualifier是 trace.感嘆號是否定符號.例如-eopen等價於 -e trace=open,表示只跟蹤open調用.而-etrace!=open表示跟蹤除了open以外的其它調用.有兩個特殊的符號 all 和 none. 注意有些shell使用!來執行歷史記錄裏的命令,所以要使用//.
-e trace=set 只跟蹤指定的系統調用.例如:-e trace=open,close,rean,write表示只跟蹤這四個系統調用.默認的爲set=all.
-e trace=file 只跟蹤有關文件操作的系統調用.
-e trace=process 只跟蹤有關進程控制的系統調用.
-e trace=network 跟蹤與網絡有關的所有系統調用.
-e strace=signal 跟蹤所有與系統信號有關的系統調用.
-e trace=ipc 跟蹤所有與進程通訊有關的系統調用.
-e abbrev=set 設定strace輸出的系統調用的結果集.-v 等與 abbrev=none.默認爲abbrev=all.
-e raw=set 將指定的系統調用的參數以十六進制顯示.
-e signal=set 指定跟蹤的系統信號.默認爲all.如 signal=!SIGIO(或者signal=!io),表示不跟蹤SIGIO信號.
-e read=set 輸出從指定文件中讀出的數據.例如-e read=3,5
-e write=set 輸出寫入到指定文件中的數據.
-o filename 將strace的輸出寫入文件filename
-p pid 跟蹤指定的進程pid.
-s strsize 指定輸出的字符串的最大長度.默認爲32.文件名一直全部輸出.
-u username 以username 的UID和GID執行被跟蹤的命令.
4 用strace調試程序
在理想世界裏, 每當一個程序不能正常執行一個功能 時, 它就會給出一個有用的錯誤提示, 告訴在足夠的改正錯誤的線索. 但遺憾的是, 我們不是生活在理想世界裏, 起碼不總是生活在理想世界裏. 有時 候一個程序出現了問題, 無法找到原因. 這就是調試程序出現的原因. strace是一個必不可少的調試工具, strace用來監視系統調用. 不僅 可以調試一個新開始的程序, 也可以調試一個已經在運行的程序(把strace綁定到一個已有的PID上 面).
首先讓我們看一個真實的例子:
啓動KDE時出現問題, 前一段時間, 我在啓動KDE的時候出了問題, KDE 的錯誤信息無法給我任何有幫助的線索.
|
|
對我來說這個錯誤信息沒有太多意義, 只是一個對KDE 來說至關重要的負責進程間通信的程序無法啓動. 我還可以知道這個錯誤和ICE協議(Inter Client Exchange)有關, 除此之 外, 我不知道什麼是KDE啓動出錯的原因. 我決定採用strace看一下在啓動 dcopserver時到底程序做了什麼:
|
|
這裏 -f -F選項告訴strace同時跟蹤fork 和vfork出來的進程, -o選項把所有strace輸出寫到~/dcop-strace.txt裏 面, dcopserver是要啓動和調試的程 序. 再次出現錯誤之後, 我檢查了錯誤輸出文件dcop-strace.txt, 文件裏有很多系統調用的記錄. 在程序運行出錯前的有關記錄如下:
其中第一行顯示程序試圖創建/tmp/.ICE- unix目錄, 權限爲0777, 這個操作因爲目錄已經存在而失敗了. 第二個系統調用(lstat64)檢查了目錄狀態, 並顯示這個目錄的權限是 0755, 這裏出現了第一個程序運行錯誤的線索: 程序試圖創建屬性爲0777的目錄, 但是已經存在了一個屬性爲 0755的目錄. 第三個系統調用 (unlink)試圖刪除一個文件, 但是這個文件並不存在. 這並不奇怪, 因爲這個操作只是試圖刪掉可能存在的老文件.
但是, 第四行確認了錯誤所在. 它試圖綁定到/tmp /.ICE-unix/dcop27207-1066844596, 但是出現了拒絕訪問錯誤. ICE_unix目錄的用戶和組都是root, 並且只 有所有者具有寫權限. 一個非root用戶無法在這個目錄下面建立文件, 如果把目錄屬性改成0777, 則前面的操作有可能可以執行, 而這正是第一 步錯誤出現時進行過的操作.
所以我運行了chmod 0777 /tmp /.ICE-unix之後KDE就可以正常啓動了, 問題解決了, 用strace進行跟蹤調試只需要花很短的幾分鐘時間跟蹤程序運行, 然後檢查並分析 輸出文件.
說明: 運行chmod 0777只是一個測試, 一般 不要把一個目錄設置成所有用戶可讀寫, 同時不設置粘滯位(sticky bit). 給目錄設置粘滯位可以阻止一個用戶隨意刪除可寫目錄下面其它人的文 件. 一般會發現/tmp目錄因爲這個原因設置了粘滯位. KDE可以正常啓動之後, 運行chmod +t /tmp/.ICE-unix 給.ICE_unix設置粘滯位.
5用strace解決庫依賴問題
starce 的另一個用處是解決和動態庫相關的問題. 當對一個可執行文件運行ldd 時, 它會告訴程序使用的動態庫和找到動態庫的位置. 但是如果正在使用一個比較老的glibc版本(2.2或更早), 可能會有一個有bug的ldd程 序, 它可能會報告在一個目錄下發現一個動態庫, 但是真正運行程序時動態連接程序 (/lib/ld-linux.so.2)卻可能到另外一個目錄去找 動態連接庫. 這通常因爲/etc/ld.so.conf和 /etc/ld.so.cache文件不一致, 或者/etc/ld.so.cache被破 壞. 在glibc 2.3.2版本上這個錯誤不會出現, 可能ld-linux的這個bug已經被解決了.
儘管這樣, ldd並不能把所有程序依賴的動態庫列出 來, 系統調用dlopen可以在需要的時候自動調入需要的動態庫, 而這些庫可能不會被ldd列出來. 作爲glibc的一部分的 NSS(Name Server Switch)庫就是一個典型的例子, NSS的一個作用就是告訴應用程序到哪裏去尋找系統帳號數據庫. 應用程序不會 直接連接到NSS庫, glibc則會通 過dlopen自動調入NSS庫. 如果這樣的庫偶然丟失, 不會被告知存在庫依賴問題, 但這樣的程序就無法 通過用戶名解析得到用戶ID了.
讓我 們看一個例子:
whoami程序會給出自己的用戶名, 這個程序在一些 需要知道運行程序的真正用戶的腳本程序裏面非常有用, whoami的一個示 例輸出如下:
|
|
假設因爲某種原因在升級 glibc的過程中負責用戶名 和用戶ID轉換的庫NSS丟失, 我們可以通過把nss庫改名來模擬這個環境:
|
|
這裏可以看到, 運行whoami時出現了錯 誤, ldd程序的輸出不會提供有用的幫助:
只會看到whoami依賴Libc.so.6和ld-linux.so.2, 它沒有給出運行 whoami所必須的其它庫. 這裏時用strace跟蹤 whoami時的輸出:
|
|
可以發現在不同目錄下面查找libnss.so.2的嘗 試, 但是都失敗了. 如果沒有strace這樣的工具, 很難發現這個錯誤是由於缺少動態庫造成的. 現在只需要找到libnss.so.2並把它放回 到正確的位置就可以了.
6 限制strace只跟蹤特定的系統調用
如果 已經知道要找什麼, 可以讓strace只跟蹤一些類型的系統調用. 例如, 需要看看在configure腳本里面執行的程序, 需要監視的系統調用就 是execve. 讓strace只記錄execve的調用用這個命令:
|
|
部分輸出結果爲:
已經看到了, strace不僅可以被程序員使用, 普 通系統管理員和用戶也可以使用strace來調試系統錯誤. 必須承認, strace的輸出不總是容易理解, 但是很多輸出對大多數人來說是不重要 的. 會慢慢學會從大量輸出中找到可能需要的信息, 像權限錯誤, 文件未找到之類的, 那時strace就會成爲一個有力的工具了.