生產環境遇到一個神奇的問題，某個進程運行一段時間后，就莫名其妙地被干掉了。初步懷疑是被操作系統OOM killer干掉的，但查看了dmesg日志以及系統內存監控數據，發現內存充足也沒有達到cgroup限制，排除了操作系統OMM killer干的。

應該是被其他進程干掉了，但系統里面進程這么多，怎么知道是哪個進程發出的kill信號呢?我們知道，sigkill(kill -9)是無法屏蔽并且不允許注冊handler的。

今天給大家介紹一個神器bpftrace，之前介紹BPF入門的文章里面已經介紹了通過bpf攔截sys_clone系統調用了。原理類似，我們可以通過bpftrace攔截kill系統調用，從而找出殺死進程的罪魁禍首。

腳本非常簡單，如下所示，主要就是在進入系統調用sys_enter_kill注冊 以及 結束系統調用sys_exit_kill的時候獲取并打印發出信號的pid和信號編號。

BEGIN 
{ 
    printf("Tracing kill() signals... Hit Ctrl-C to end.\n"); 
    printf("%-9s %-6s %-16s %-4s %-6s %s\n", "TIME", "PID", "COMM", "SIG", 
        "TPID", "RESULT"); 
} 
 
tracepoint:syscalls:sys_enter_kill 
{ 
    @tpid[tid] = args->pid; 
    @tsig[tid] = args->sig; 
} 
 
tracepoint:syscalls:sys_exit_kill 
/@tpid[tid]/ 
{ 
    time("%H:%M:%S  "); 
    printf("%-6d %-16s %-4d %-6d %d\n", pid, comm, @tsig[tid], @tpid[tid], 
        args->ret); 
    delete(@tpid[tid]); 
    delete(@tsig[tid]); 
} 

我們可以先啟動一個sleep的Demo測試

# sleep 444 

執行上面的腳本后，通過 ”kill -9 “殺死上面啟動sleep 任務，可以腳本輸出如下：

TIME      PID    COMM             SIG  TPID   RESULT 
11:38:43  2837583 bash             9    2837548 0 

其中，TIME代表執行時間，PID代表發出信號的進程ID，COMM代表發出信號進程命令行，由于是在bash環境中執行的kill -9 所以這里顯示bash，SIG代表信號編號，本例中是kill -9 信號，TPID是sleep任務的線程ID，RESULT代表執行結果，0代表成功。”殺手“和”受害者“都已經成功顯示。

最終通過上面的腳本找到了系統上面一個自動清理程序，由于使用了通配符導致誤殺的情況。