生产环境遇到一个神奇的问题，某个进程运行一段时间后，就莫名其妙地被干掉了。初步怀疑是被操作系统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代表成功。”杀手“和”受害者“都已经成功显示。
最终通过上面的脚本找到了系统上面一个自动清理程序，由于使用了通配符导致误杀的情况。
