鑑於這似乎被卡在Linux機器上的過程,我怎麼能告訴如果還停留由於STDOUT或STDERR緩衝區已滿?如何檢查的過程充滿了stdout或stderr緩衝
在我的具體情況,我也正在執行沒有CPU活動的過程,但是當我希望它已在幾秒鐘內退出保持運行。我懷疑這個過程已經填滿了STDOUT或STDERR的緩衝區,以及由於某種原因應該從緩衝區停止讀取的過程。
有什麼辦法可以證實這種懷疑嗎?
鑑於這似乎被卡在Linux機器上的過程,我怎麼能告訴如果還停留由於STDOUT或STDERR緩衝區已滿?如何檢查的過程充滿了stdout或stderr緩衝
在我的具體情況,我也正在執行沒有CPU活動的過程,但是當我希望它已在幾秒鐘內退出保持運行。我懷疑這個過程已經填滿了STDOUT或STDERR的緩衝區,以及由於某種原因應該從緩衝區停止讀取的過程。
有什麼辦法可以證實這種懷疑嗎?
這是一個std Linux的過程中,專門安裝第三方軟件包或定製編寫的代碼?
標準Linux進程不應該有這樣的問題,而自定義代碼是最有可能的罪魁禍首。調試這種情況的最簡單方法是添加特殊的調試代碼。
否則,看看是否您的STD實用程序或第三方封裝具有冗餘模式,往往-v, or -vv, or -vvv
。
最後,對於某些Linux版本,您可以使用您的操作系統版本truss (for solaris)
,strace
來查看掛載的位置。
IHTH
這是一個在這裏開發的C程序,它由一些Java代碼(也是我們自己的設計)發起的,但它不是可重現的情況,所以我試圖從已經運行的過程中獲得什麼信息在我殺死它之前。 –
實際上,雖然-v等是有趣的,但是strace幾乎總是可以放在正確的位置(通過函數名),問題是,通常你可以知道100個「printf」的哪個位置(例如)在你的代碼中被調用。希望你看到的參數和值可以讓你知道你的代碼庫中哪一行是掛起的。企業級系統中的高概率是磁盤集羣中的特定驅動器。好luk。 – shellter
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
所以這是答案?或更多的證據供人們使用? :-) 祝你好運。 – shellter
從我的角度來看,我認爲我已經證實了我的理論(當兩天的等待期結束時我會接受這個答案),除非有人提供了更完整/徹底的答案:) –
另一種理論如果不能平移 - 我可以檢查過程是否被阻塞,等待在STDIN上的輸入? –