Linux查找是发送SIGKILL信号的进程

背景

最近在开发服务器上遇到了一件奇怪的事情，同事反馈之前运行着正常的程序，现在现在运行一段时间会退出，而且没有日志输出。询问后，出现这个现象是在周末由于停电重启之后。

停电重启？退出，无日志？有关系吗？

问题定位

由于程序在常驻，所以使用了两个进程相互守护。是守护出了问题吗？如果是的话，应该会有日志输出。在服务器上查看程序的过程中又发现新的疑点，使用vim打开带有push的文件名的文件，一段时间之后会被杀死，显示：

killed

这么粗暴吗？查看返回值：

$ echo $?
137

说明程序是接收到了SIGKILL的信号，而被杀的程序也包括push。下一步就是确认是谁发送的SIGKILL信号，由于SIGKILL信号是不能被捕捉和处理的，程序里面好像没有什么可以做的事情了。那么操作系统有不有什么记录呢？

经过查找使用audit可以记录SIGKILL信号。

audit

audit是用户空间的一个组件，一般默认安装，配合内核的审计模块一起工作。可以记录与安全相关的内核事件。

安装：

$ yum list audit audit-libs

配置文件在：

/etc/audit/auditd.conf

规则文件在：

/etc/audit/audit.rules

日志文件在：

/var/audit/audit.log

在规则文件中添加：

-a entry,always -F arch=b64 -S kill -k kill_signals

如果是32位的系统将b64替换为b32。其他参数具体说明查看man auditctl。

启动/重启服务：

# service auditd start
# service auditd restart

启动被杀的程序，等待被杀死。

查看日志：

# tailf /var/log/audit/audit.log

也可以使用附带工具：

# ausearch -k teste_kill

类似输出：

time->Thu Jan 10 16:58:57 2018
type=OBJ_PID msg=audit(1515661137.703:156743): opid=29236 oauid=0 ouid=0 oses=23836 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm="push"
type=SYSCALL msg=audit(1515661137.703:156743): arch=c000003e syscall=62 success=yes exit=0 a0=7234 a1=9 a2=0 a3=7234 items=0 ppid=48597 pid=24814 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts9 ses=23836 comm="sh" exe="/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="teste_kill"

这里面去找pid为48597的进程吧，就是它干的坏事。

48597里面调用命令行命令，ps，kill等进行的定时任务的监控。

至此已经找到元凶。

还有一个疑点，为什么在周末重启之后才这个现象呢？因为之前这个程序已经停止了，没有人知道，重启之后都重新启动了。尴尬~~~

总结

相关进程进行守护时，最好使用进程id进行辨识，不要使用进程名字，早晚会出问题。

服务端程序设计时，不要为省时而缺少设计。否则后续添加的功能，会把之前的架构压垮。即时重构。

做了坏事，就会留痕迹。

参考

https://access.redhat.com/solutions/36278