Linux進程死鎖定位

最近定位一個服務問題時發(fā)現(xiàn)telnet某個端口，無法鏈接。無奈之下只能一步步排查。

10多年的阜康網站建設經驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。全網整合營銷推廣的優(yōu)勢是能夠根據用戶設備顯示端的尺寸不同，自動調整阜康建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“阜康網站設計”,“阜康網站推廣”以來，每個客戶項目都認真落實執(zhí)行。

端口是否存在

ss -l|grep LISTEN|grep 9999

如果端口存在那么可以觀察該端口上的recv-q send-q 如果是發(fā)生死鎖一般情況下這兩個隊列只會增加（當然當服務處理過慢時也會導致包堆積）

Recv-Q Send-Q Local Address:Port Peer Address:Port 
0 1024 *:5200 *:* 

0. 另外可以通過一下命令統(tǒng)計各類socket 狀態(tài)的數據

   ss |awk 'BEGIN{arr[""]=0}{arr[$1]++}END{for(i in arr) print i,arr[i]}'
   LAST-ACK 1305
   ESTAB 341643
   State 1
   FIN-WAIT-1 7553
   CLOSING 3
   FIN-WAIT-2 908
   CLOSE-WAIT 60067

   如果你的服務是多個進程那么，如果只是一個進程死鎖，那么很容易就可以看出來該進程的cpu消耗時間應該小于其他進程，當然這個取決于進程的運行時間。下面的進程中，id=1903的進程就是疑似死鎖問題。

   
   root 1901 1 0 11:09 ? 00:00:00 ./client -f ../conf/client.ini -d

root 1902 1901 15 11:09 ? 00:31:55 ./client -f ../conf/client.ini -d

root 1903 1901 1 11:09 ? 00:02:25 ./client -f ../conf/client.ini -d

root 1904 1901 15 11:09 ? 00:31:19 ./client -f ../conf/client.ini -d

root 1905 1901 15 11:09 ? 00:31:17 ./client -f ../conf/client.ini -d

定位哪里死鎖

經過一步步盤查之后，懷疑進程死鎖，ok。最好的定位方法就是attach到進程，然后bt一下既可以看到進程hang在哪里。。。

$gdb attach 1903

#0 0x00007f105892105e in __lll_lock_wait_private () from /lib64/libc.so.6

#1 0x00007f10588c6cad in _L_lock_2164 () from /lib64/libc.so.6

#2 0x00007f10588c6a67 in __tz_convert () from /lib64/libc.so.6

#3 0x00007f105890da5d in __vsyslog_chk () from /lib64/libc.so.6

#4 0x00007f105889948e in __libc_message () from /lib64/libc.so.6

#5 0x00007f105889ee66 in malloc_printerr () from /lib64/libc.so.6

#6 0x00007f10588c6909 in tzset_internal () from /lib64/libc.so.6

#7 0x00007f10588c6a89 in __tz_convert () from /lib64/libc.so.6

#8 0x00000000004c0917 in shift_fd (lvl=1, fmt=0x55e308 "[%s][%d][%s]: [server] recv SIGSEGV.pid:%d!\n") at ../src/log_xx.cpp:95

#9 write_log (lvl=1, fmt=0x55e308 "[%s][%d][%s]: [server] recv SIGSEGV.pid:%d!\n") at ../src/log_xx.cpp:138

上面這個問題導致是因為進程拋出了SEGV信號之后，在處理信號的方法中使用了非線程安全的localtime，而該方法中會枷鎖。