|
背景
最近在开发服务器上遇到了一件奇怪的事情，同事反馈之前运行着正常的程序，现在现在运行一段时间会退出，而且没有日志输出。询问后，出现这个现象是在周末由于停电重启之后。
停电重启？退出，无日志？有关系吗？
问题定位
由于程序在常驻，所以使用了两个进程相互守护。是守护出了问题吗？如果是的话，应该会有日志输出。在服务器上查看程序的过程中又发现新的疑点，使用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
|