谁是linux SIGKILL的凶手---linux审计日志排障的杀手锏

一、背景描述

在我们的技术生涯中，总会碰到那精彩的一瞬间，哪怕是一瞬间，曾经的熟悉php内核的同事和今天碰到的排障瞬间，都是我技术生涯中那精彩的一瞬间，写一篇日志记录一下。

今天碰到一个问题，就是采集器的agent 总是被另一个进程在5分钟之后杀掉

具体现象

# sudo strace -p 6574
strace: Process 6574 attached
restart_syscall(<... resuming interrupted read ...>

过了一会收到SIGKILL 信号

# sudo strace -p 6574
strace: Process 6574 attached
restart_syscall(<... resuming interrupted read ...>) = ?
+++ killed by SIGKILL +++

那么我们现在面临的问题是如何找到发送SIGKILL的真凶。我们知道linux 信号里和其他信号还不一样，比如说SIGTERM 是可捕获的，SIGKILL 是不可捕获的，当进程收到信号的时候进程会被操作系统强制杀掉，这也给我排障带来了很大的障碍。

二、谁是SIGKILL真凶的搜查之旅

1）初步使用strace 排障

当出现这个问题的时候我们使用strace 进行排障

具体命令如下

$ sudo strace -p 7000 -e trace=signal

具体排查效果

strace: Process 7000 attached
--- SIGTERM {si_s