1. 程式人生 > >Linux 使用strace命令查詢程序卡死原因

Linux 使用strace命令查詢程序卡死原因

最近遇到程序卡死的情況,但是自己除錯的過程中並不一定能復現,都是需要執行一段時間某些條件下才會觸發,對於這種執行著不能破壞現場的情況,我們可以使用gdb -p和strace -p來跟蹤。 
首先我們用ps auxf檢視我們的程序執行到了哪一步: 
這裡寫圖片描述
可以看到執行到了docker exec -i 178.20.1.229_0115034556 ls然後就卡死了 
然後我們進一步通過strace檢視執行這個操作死在哪個系統回調了: 
這裡寫圖片描述
這裡可以看到死在了系統回撥read這裡,描述符19的具體意義我們可以進入/proc/pid/fd再檢視一下: 
這裡寫圖片描述 
我們可以發現,19代表的是pipe,我們這裡是死在了讀pipe上面。 
/**********************************************************************************************************************


分割線,後面再次出現這個問題 
我們先用ps auxf檢視程序號和程序執行到了哪一步,可以看到程序號是27678,卡在docker exec

root     27678  0.3  0.4 512172 16500  Sl    python /wns/cloud/app/com_host/main.pyc
root     25011  0.0  0.0   4332   652  S      \_ /bin/sh -c docker exec -i mongo_docker_master ls
root     25014  0.0  0.2 136592 10600  Sl         \_ docker exec -i mongo_docker_master ls

繼續用strace -p 27678跟蹤,發現卡在read,檔案描述符是14

root@localhost:/# strace -p 27678      
Process 27678 attached
read(14,

接著我們cd /proc/27678/,在這裡我們可以檢視程序狀態

[email protected]:/proc/27678# cat status 
Name:   python
State:  S (sleeping)
Tgid:   27678
Ngid:   0
Pid:    27678
PPid:   27677

檢視程序的核心堆疊的除錯資訊,wchan表示導致程序睡眠或者等待的函式

root@localhost:/proc/27678# cat stack 
[<ffffffff811a91ab>] pipe_wait+0x6b/0x90
[<ffffffff811a9c04>] pipe_read+0x344/0x4f0
[<ffffffff811a00bf>] do_sync_read+0x7f/0xb0
[<ffffffff811a0681>] vfs_read+0xb1/0x130
[<ffffffff811a1110>] SyS_read+0x80/0xe0
[<ffffffff818d4c49>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
root@localhost:/proc/27678# cat wchan 
pipe_wait

現在我們檢視一下程序開啟的檔案描述符14代表什麼,pipe檔案

root@localhost:/proc/27678# ls -l ./fd
total 0
lr-x------ 1 root root 64 Mar 26 17:19 0 -> pipe:[30690124]
l-wx------ 1 root root 64 Mar 26 17:19 1 -> pipe:[30690125]
lrwx------ 1 root root 64 Mar 26 17:19 10 -> socket:[30691732]
lr-x------ 1 root root 64 Mar 26 17:19 11 -> /dev/urandom
lrwx------ 1 root root 64 Mar 26 17:19 12 -> socket:[30719611]
lrwx------ 1 root root 64 Mar 26 17:19 13 -> socket:[30719610]
lr-x------ 1 root root 64 Mar 26 17:19 14 -> pipe:[38483750]

我們已經可以確定main建立子程序執行shell命令docker exec -i mongo_docker_master ls,同時通過pipe和子程序通訊,結果卡在了read pipe上。 
其實在這裡我們也可以使用lsof來定位,可以看到程序27678開啟的FD 14是pipe,這裡u代表可讀可寫,r代表可讀

sangfor ~ # lsof -d 14
COMMAND     PID USER   FD   TYPE             DEVICE SIZE/OFF     NODE NAME
mongod     1907 root   14u   REG              251,0    36864   130683 /wns/data/mongodb/db/collection-7--588642557116981989.wt
syslog-ng  3446 root   14u  unix 0xffff88012227d800      0t0 40557736 /dev/log
dockerd    4025 root   14u  unix 0xffff8800b8d5d800      0t0    13941 /run/docker/libnetwork/a73bd949b5fbb89c2b8bec3b4ac6af0a948a944958c8b037d9e6c9b324b44331.sock
docker-co  9382 root   14u  0000                0,9        0     9553 anon_inode
docker-co 21204 root   14u  0000                0,9        0     9553 anon_inode
python    27678 root   14r  FIFO                0,8      0t0 38483750 pipe

也可以直接檢視程序27678開啟的,可以看到14是pipe

sangfor ~ # lsof -p 27678
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF     NODE NAME
python  27678 root    0r  FIFO                0,8      0t0 30690124 pipe
python  27678 root    1w  FIFO                0,8      0t0 30690125 pipe
python  27678 root    2w  FIFO                0,8      0t0 30690126 pipe
python  27678 root    3u  0000                0,9        0     9553 anon_inode
python  27678 root    4u  0000                0,9        0     9553 anon_inode
python  27678 root    5u  pack           30691718      0t0  unknown type=SOCK_RAW
python  27678 root    6w   REG              251,0 76106652   130565 /wns/data/com_host/etc/config/err.log
python  27678 root    7u  IPv4           30691716      0t0      TCP Sangfor:53102->Sangfor:42457 (ESTABLISHED)
python  27678 root    8u  IPv4           30691717      0t0      TCP Sangfor:42457->Sangfor:53102 (ESTABLISHED)
python  27678 root    9u  IPv4           30691731      0t0      TCP db.sdwan:54072->sdwan.io:27017 (ESTABLISHED)
python  27678 root   10u  IPv4           30691732      0t0      TCP db.sdwan:54074->sdwan.io:27017 (ESTABLISHED)
python  27678 root   11r   CHR                1,9      0t0 30690329 /dev/urandom
python  27678 root   12u  IPv4           30719611      0t0      TCP db.sdwan:51404->db.sdwan:37017 (ESTABLISHED)
python  27678 root   13u  IPv4           30719610      0t0      TCP db.sdwan:47124->db.sdwan:27017 (ESTABLISHED)
python  27678 root   14r  FIFO                0,8      0t0 38483750 pipe

相關推薦

Linux 使用strace命令查詢程序原因

最近遇到程序卡死的情況,但是自己除錯的過程中並不一定能復現,都是需要執行一段時間某些條件下才會觸發,對於這種執行著不能破壞現場的情況,我們可以使用gdb -p和strace -p來跟蹤。 首先我們用ps auxf檢視我們的程序執行到了哪一步: 可以看到執行到了docker exec -i 178.20.1.2

Linux下如何用/proc命令查詢程序狀態資訊——當前目錄,記憶體佔用,描述符等

參加阿里的面試,問到一個問題,如何在Linux下使用命令列查詢程序的狀態資訊,比如程序的當前目錄,程序的記憶體佔用等情況。當時的第一反應是使用top命令能夠得到所有的程序資訊。但是面試官好像不是很滿意,因此我回去之後查閱了相關的資料,發現可能他想問的/proc目錄,我這裡整

Linux用ps命令查詢程序PID再用kill命令終止程序的方法

使用linux作業系統,難免遇到一些軟體"卡殼"的問題,這時就需要使用linux下強大的kill命令來結束相關程序。這在linux系統下是極其容易的事情,你只需要kill xxx即可,這裡xxx代表與此軟體執行相關的程序PID號。    首先,我們需要使用linux下另外一

FreeRTOS 啟動進程調度後,程序的部分原因分析。

定義 eight c中 current 分享圖片 技術分享 ref 1-1 tin 現象:1,RTOS 使用時 系統卡啟動文件 B .處。原因分析:該種情況是由於定義開啟了中斷,但是未開啟中斷處理服務。程序執行到中斷響應式無對應的程

Linux strace命令

family title qualifier 輸入 除了 lena 一段 建立 部分 轉自:https://www.cnblogs.com/ggjucheng/archive/2012/01/08/2316692.html 簡介 strace常用來跟蹤進程執行時的系統調

應用程序如何排查

應用程序卡死 排查思路 故障排查 linux排查 一.應用程序卡死如何排查故障:客服報障,平臺點擊界面菜單無反應排查步驟:1.首先先從公司架構入手,2個節點2層代理負載再到後端web,程序再調用中間件,最後才到數據庫2.先把負載卸掉,用單節點單負載進行訪問3.如果不行,再連接數據庫服務器,用t

linux——grep命令 查詢目錄下的所有檔案中是否含有某個字串

linux查詢目錄下的所有檔案中是否含有某個字串 [[email protected]]# grep -rn "runlog" * 說明: -r 是遞迴查詢 -n 是顯示行號 * : 表

Linux終端下 Ctrl+S 無法輸入問題

Linux終端下Ctrl+S卡死 第一次遇到 在vim插入模式下,習慣使用Ctrl+s儲存一下(在windows下的習慣),但是之後終端會卡死; 解決辦法 原因是在終端下“CTRL+S”代表鎖定螢幕顯示,使用“CTRL+Q”退出即可(解除之後,會出現在鎖定期間輸入

linux grep命令(查詢檔案裡符合條件的字串)

b124230 b034325 b103303 b044525 # more size.txt | grep '[bB]' b124230 b034325 b103303 b044525 B081016 B103303 BADc2345 # grep 'root' /etc/group root::0:ro

vc2010 一執行整個專案查詢情況!

解決辦法如下: 解決方法:找到VS2010的安裝目錄,修改"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE"目錄下的devenv.exe的屬性,將其“相容性”中的“禁用視覺主題”打鉤。 效

一個主程序的跟蹤

原因:一開始想查詢由於ipc初始化順序的問題導致tray卡死的原因,但恰好遇到主程序彈出退出確認框後也卡死了,於是開始查詢原因. 首先是跟蹤程式碼,發現訊息迴圈是活著的,但整個訊息迴圈只能取到timer和paint訊息,使用訊息工具抓視窗,可以看到也可以取到GetItem

linux新伺服器df -h

新接手一個伺服器,昨天df -h還好好的,今天突然不行了,卡死,ctrl+C都沒用,就各種找原因啊。。。 這種問題要不是有兩種情況,如果有網路盤掛載,如nfs、samba這類掛載,很有可能對端服務失效,目錄卡死的原因, 如果沒有這種網路掛載的話,就是本地目錄卡死的功能。

關於實體機安裝Linux系統時LOGO處問題解決辦法

實體機型號:Lenovo thinkpad E425 安裝的Linux版本:linuxmint-17.1-cinnamon-64bit                                  ubuntukylin-15.04-desktop-amd64     

firefox在位址列輸入地址原因及解決方案

此方法無效,此問題暫未解決! 新安裝了幾個系統更新之後發現,在firefox位址列輸入地址,輸入幾個字母之後就會卡死 網上查閱資料發現(參照:http://blog.sina.com.cn/s/blog_49d9aa0f0101k248.html),可能跟我筆記本的整合顯

flock導致程序, 如何檢視

具體的用法檢視man flock就ok了。 因為遇到用flock鎖一直鎖住的情況,所以想寫個指令碼看看到底是哪個程序一直佔著資源。 用法:開幾個shell視窗,執行此指令碼,tailf  /tmp/gaussdbControl,檢視程序獲得鎖和釋放鎖的情況,同時可以用lso

Linux strace命令---跟蹤程式執行

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

Linux strace工具,程序診斷、排錯、跟蹤系統呼叫和訊號量

strace 跟蹤系統呼叫和訊號量,是一個很好的診斷、排錯的工具。 每行輸出都是一個系統呼叫,包括函式和返回值。 示例--直接列印資訊的方式 [[email protected] ~]$ strace cat /dev/null execve("/bin/cat

linux 常用到的命令 刪除 移動 複製 查詢埠 殺死程序 查詢程序

1. 刪除檔案 刪除一個檔案 rm -f 檔案路徑 刪除多個檔案 rm -f 檔案路徑 檔案路徑 ... 刪除資料夾以及資料夾中的檔案 rm -rf 資料夾路徑 刪除多個資料夾以及資料夾中的檔案 rm -rf 資料夾路徑 資料夾路徑 ...

linux 某個資料夾執行命令完全完美解決方法

某個資料夾執行命令完全卡死(ctrl+z,ctrl+c等都不能用)表現: 1.在資料夾執行ls等命令卡死; 2.在伺服器任何地方執行df -h卡死(sudo fdisk -l管用); 3.cd 資料夾

Linux下用 lsof 命令查詢指定埠被哪個程序佔用

lsof(list open files)是一個列出當前系統開啟檔案的工具。在Linux環境下,任何事物都以檔案的形式存在,通過檔案不僅僅可以訪問常規資料,還可以訪問網路連線 和硬體。所以如傳輸控制協議 (tcp) 和使用者資料報協議 (udp) 套接字等,系統在後臺都為該應用程式分配了一個檔案描述符,無論