2013-01-21 86 views
0

鑑於這似乎被卡在Linux機器上的過程,我怎麼能告訴如果還停留由於STDOUT或STDERR緩衝區已滿?如何檢查的過程充滿了stdout或stderr緩衝

在我的具體情況,我也正在執行沒有CPU活動的過程,但是當我希望它已在幾秒鐘內退出保持運行。我懷疑這個過程已經填滿了STDOUT或STDERR的緩衝區,以及由於某種原因應該從緩衝區停止讀取的過程。

有什麼辦法可以證實這種懷疑嗎?

+0

另一種理論如果不能平移 - 我可以檢查過程是否被阻塞,等待在STDIN上的輸入? –

回答

1

這是一個std Linux的過程中,專門安裝第三方軟件包或定製編寫的代碼?

標準Linux進程不應該有這樣的問題,而自定義代碼是最有可能的罪魁禍首。調試這種情況的最簡單方法是添加特殊的調試代碼。

否則,看看是否您的STD實用程序或第三方封裝具有冗餘模式,往往-v, or -vv, or -vvv

最後,對於某些Linux版本,您可以使用您的操作系統版本truss (for solaris),strace來查看掛載的位置。

IHTH

+0

這是一個在這裏開發的C程序,它由一些Java代碼(也是我們自己的設計)發起的,但它不是可重現的情況,所以我試圖從已經運行的過程中獲得什麼信息在我殺死它之前。 –

+0

實際上,雖然-v等是有趣的,但是strace幾乎總是可以放在正確的位置(通過函數名),問題是,通常你可以知道100個「printf」的哪個位置(例如)在你的代碼中被調用。希望你看到的參數和值可以讓你知道你的代碼庫中哪一行是掛起的。企業級系統中的高概率是磁盤集羣中的特定驅動器。好luk。 – shellter

0

關於你的替代理論,看看SO。我發現this有趣,我希望這裏的東西很有用。 CHEERS

+0

你有沒有試過pidstat? (:http://khaidoan.wikidot.com/pidstat)向您展示瞭如何使用它來獲取關於I/O問題以及關於您的流程的其他信息的一些信息,如果您擁有現代化的內核並且您已設置好正確。 CHEERS –

1

GDB連接並運行回溯幾乎證實了我的理論......

$ gdb /opt/our_process pid 
...blah blah blah... 
(gdb) bt 
#0 0x0000003f27adae60 in __write_nocancel() from /lib64/libc.so.6 
#1 0x0000003f27a71583 in _IO_new_file_write() from /lib64/libc.so.6 
#2 0x0000003f27a7144a in _IO_new_file_xsputn() from /lib64/libc.so.6 
#3 0x0000003f27a49531 in buffered_vfprintf() from /lib64/libc.so.6 
#4 0x0000003f27a4449e in vfprintf() from /lib64/libc.so.6 
#5 0x0000003f27a4f03a in printf() from /lib64/libc.so.6 
...out process's stack... 

而且strace的作爲shelter suggested也好像它會做的伎倆......

$ strace -p 27689 
Process 27689 attached - interrupt to quit 
write(1, "some_text"..., 293 
+0

所以這是答案?或更多的證據供人們使用? :-) 祝你好運。 – shellter

+0

從我的角度來看,我認爲我已經證實了我的理論(當兩天的等待期結束時我會接受這個答案),除非有人提供了更完整/徹底的答案:) –