ulimit限制導致的 +++ killed by SIGKILL +++

westzq1984發表於2013-11-14
MIT
昨天和同事解決了一個案例，主要是同事解決的，我只是提了些建議。

一套系統的監聽，不定時的宕掉，是直接就不見了。
最後確定為ulimit中，限制了程式使用的CPU時間數，超過限制值，系統就會粗暴的直接使用kill -9將程式給幹掉

模擬下，在/etc/security/limits.conf中設定
  oracle soft cpu 1
  oracle hard cpu 1

進行ORACLE使用者後檢視ulimit值,CPU時間已經被限定到60s
[oracle@zhangqiaoc ~]$ ulimit -t
60

編寫一個指令碼不停的連線資料庫
while ((1<2))              
do
 sqlplus -s ctais2/oracle@o11203 @exit.sql
done

同時使用strace跟蹤監聽
strace -fo /tmp/strace.out -p 19882

發現監聽接收到SIGKILL訊號被殺掉。多次測試均一致
19884 +++ killed by SIGKILL +++
19883 +++ killed by SIGKILL +++
19882 +++ killed by SIGKILL +++

然後模擬對監聽執行kill -9 ，檢視strace的輸出，一致
5085  +++ killed by SIGKILL +++
5086  +++ killed by SIGKILL +++
5084  +++ killed by SIGKILL +++

只說明，監聽是被kill掉的，那麼是何程式kill的監聽？
通過 .bash_history  檢查，不會發現任何異常命令

strace.out也無法找到更多的資訊
但是這個情況，給人的感覺就是監聽使用資源到達一定程度，被殺掉了

GOOGLE一下LIMIT的資源限制，可以看到基本都降到ulimit，其中對於CPU限制：
  最大允許的CPU使用時間，秒為單位。當程式達到軟限制，核心將給其傳送SIGXCPU訊號，這一訊號的預設行為是終止程式的執行。
  然而，可以捕捉訊號，處理控制程式碼可將控制返回給主程式。如果程式繼續耗費CPU時間，核心會以每秒一次的頻率給其傳送SIGXCPU訊號，直到達到硬限制，
  那時將給程式傳送 SIGKILL訊號終止其執行。
 
在LINUX上，可以使用stap捕獲sigkill訊號，獲得是被何程式kill的
$ cat sigkill.stp
probe signal.send{
  if(sig_name == "SIGKILL")
    printf("%s was sent to %s (pid:%d) by %s uid :%d\n", sig_name, pid_name , sig_pid, execname(), uid())
}
 
$ sudo stap sigkill.stp
SIGKILL was sent to a.out (pid:23700) by a.out uid :50920

在Solaris上，理論上可以使用dtrace來捕獲sigkill訊號

從linux的原始碼中可以看到，超過硬CPU限制就是簡單粗暴的讓程式被自殺了
參考 http://blog.csdn.net/bingqingsuimeng/article/details/8599668

但是這個案例很奇怪，對於lgwr,dbwr這種程式，竟然沒有被自殺，看來是有人在資料庫啟動後，才做了這樣的更改

如何檢視程式當前限制值,只知道LINUX，其他平臺未知
[oracle@zhangqiaoc ~]$ cat /proc/7455/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              60                   60                   seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             16384                16384                processes
Max open files            65536                65536                files     
Max locked memory         5368832000           5368832000           bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       73728                73728                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    

啟示：
對於稀奇古怪的問題，一般需要先做的檢查：
1.安裝配置，特別的limit，還有hpux下的/etc/privgroup檔案
2.使用raccheck,RDA等工具檢查系統
3.strace等工具跟蹤
4.還要考慮使用ps -elf / ps vg 一直跟蹤程式的資源消耗情況

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8242091/viewspace-776610/，如需轉載，請註明出處，否則將追究法律責任。

相關文章