簡介

strace常用來跟蹤程序執行時的系統呼叫和所接收的訊號。 在Linux世界，程序不能直接訪問硬體裝置，當程序需要訪問硬體裝置(比如讀取磁碟檔案，接收網路資料等等)時，必須由使用者態模式切換至核心態模式，通 過系統呼叫訪問硬體裝置。strace可以跟蹤到一個程序產生的系統呼叫,包括引數，返回值，執行消耗的時間。

輸出引數含義

[email protected]:/usr# strace cat /dev/null 
execve("/bin/cat", ["cat", "/dev/null"], [/* 22 vars */]) = 0
brk(0)                                  = 0xab1000
 

access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f29379a7000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
...
brk(0) = 0xab1000
brk(0xad2000) = 0xad2000
fstat(1, {st_mode=S_IFCHR|0620
 
, st_rdev=makedev(136, 0), ...}) = 0
open("/dev/null", O_RDONLY) = 3
fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
read(3, "", 32768) = 0
close(3) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?

每一行都是一條系統呼叫，等號左邊是系統呼叫的函式名及其引數，右邊是該呼叫的返回值。
strace 顯示這些呼叫的引數並返回符號形式的值。strace 從核心接收資訊，而且不需要以任何特殊的方式來構建核心。

strace引數

-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執行被跟蹤的命令

命令例項

通用的完整用法：

strace -o output.txt -T -tt -e trace=all -p 28979

上面的含義是 跟蹤28979程序的所有系統呼叫（-e trace=all），並統計系統呼叫的花費時間，以及開始時間（並以視覺化的時分秒格式顯示），最後將記錄結果存在output.txt檔案裡面。

strace案例

用strace除錯程式

在理想世界裡，每當一個程式不能正常執行一個功能時，它就會給出一個有用的錯誤提示，告訴你在足夠的改正錯誤的線索。但遺憾的是，我們不是生活在理想世界 裡，起碼不總是生活在理想世界裡。有時候一個程式出現了問題，你無法找到原因。
這就是除錯程式出現的原因。strace是一個必不可少的 除錯工具，strace用來監視系統呼叫。你不僅可以除錯一個新開始的程式，也可以除錯一個已經在執行的程式（把strace繫結到一個已有的PID上 面）。
首先讓我們看一個真實的例子：啟動KDE時出現問題
前一段時間，我在 啟動KDE的時候出了問題，KDE的錯誤資訊無法給我任何有幫助的線索。

_KDE_IceTransSocketCreateListener: failed to bind listener
_KDE_IceTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_KDE_IceTransMakeAllCOTSServerListeners: failed to create listener for local

Cannot establish any listening sockets DCOPServer self-test failed.

對 我來說這個錯誤資訊沒有太多意義，只是一個對KDE來說至關重要的負責程序間通訊的程式無法啟動。我還可以知道這個錯誤和ICE協議（Inter Client Exchange）有關，除此之外，我不知道什麼是KDE啟動出錯的原因。

我決定採用strace看一下在啟動 dcopserver時到底程式做了什麼：

strace -f -F -o ~/dcop-strace.txt dcopserver

這裡 -f -F選項告訴strace同時跟蹤fork和vfork出來的程序，-o選項把所有strace輸出寫到~/dcop-strace.txt裡 面，dcopserver是要啟動和除錯的程式。

再次出現錯誤之後，我檢查了錯誤輸出檔案dcop-strace.txt，檔案裡有很多 系統呼叫的記錄。在程式執行出錯前的有關記錄如下：

27207 mkdir("/tmp/.ICE-unix", 0777) = -1 EEXIST (File exists)
27207 lstat64("/tmp/.ICE-unix", {st_mode=S_IFDIR|S_ISVTX|0755, st_size=4096, ...}) = 0
27207 unlink("/tmp/.ICE-unix/dcop27207-1066844596") = -1 ENOENT (No such file or directory)
27207 bind(3, {sin_family=AF_UNIX, path="/tmp/.ICE-unix/dcop27207-1066844596"}, 38) = -1 EACCES (Permission denied) 
27207 write(2, "_KDE_IceTrans", 13) = 13
27207 write(2, "SocketCreateListener: failed to "..., 46) = 46
27207 close(3) = 0 27207 write(2, "_KDE_IceTrans", 13) = 13
27207 write(2, "SocketUNIXCreateListener: ...Soc"..., 59) = 59
27207 umask(0) = 0 27207 write(2, "_KDE_IceTrans", 13) = 13
27207 write(2, "MakeAllCOTSServerListeners: fail"..., 64) = 64
27207 write(2, "Cannot establish any listening s"..., 39) = 39

其中第一行顯示程式試圖建立/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設定粘滯位。

解決庫依賴問題

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的一個示例 輸出如下：

# whoami
root

假設因為某種原因在升 級glibc的過程中負責使用者名稱和使用者ID轉換的庫NSS丟失，我們可以通過把nss庫改名來模擬這個環境：

# mv /lib/libnss_files.so.2 /lib/libnss_files.so.2.backup 
# whoami
whoami: cannot find username for UID 0

這裡你可以看到，執行whoami時出現了錯誤，ldd程式的輸出不會提供有用的幫助：

# ldd /usr/bin/whoami
libc.so.6 => /lib/libc.so.6 (0x4001f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

你只會看到whoami依賴Libc.so.6和ld-linux.so.2，它沒有給出執行whoami所必須的其他庫。這裡時用strace跟蹤 whoami時的輸出：

strace -o whoami-strace.txt whoami

open("/lib/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/mmx/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/i686/mmx", 0xbffff190) = -1 ENOENT (No such file or directory) 
open("/lib/i686/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/i686", 0xbffff190) = -1 ENOENT (No such file or directory)
open("/lib/mmx/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/mmx", 0xbffff190) = -1 ENOENT (No such file or directory) 
open("/lib/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib", {st_mode=S_IFDIR|0755, st_size=2352, ...}) = 0
open("/usr/lib/i686/mmx/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/i686/mmx", 0xbffff190) = -1 ENOENT (No such file or directory) 
open("/usr/lib/i686/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)

你可以發現在不同目錄下面查詢libnss.so.2的嘗試，但是都失敗了。如果沒有strace這樣的工具，很難發現這個錯誤是由於缺少動態庫造成的。現 在只需要找到libnss.so.2並把它放回到正確的位置就可以了。　

限制strace只跟蹤特定的系統呼叫

如果你已經知道你要找什麼，你可以讓strace只跟蹤一些型別的系統呼叫。例如，你需要看看在configure腳本里面執行的程式，你需要監視的系統調 用就是execve。讓strace只記錄execve的呼叫用這個命令：

strace -f -o configure-strace.txt -e execve ./configure