谁KILL了进程定位工具之auditd

测试部让查一个BUG,某台虚拟机的fantom启动不来。

我准备调试一下:

1
2
3
4
~ # python -mpdb /home/fantom/share/Python-2.7/lib/supervisor/supervisord.py -c /home/fantom/apps/super/default/conf/fantom/supervisord.conf
> /home/fantom/share/Python-2.7/lib/supervisor/supervisord.py(31)<module>()
-> """
(Pdb) Killed

发现刚启动就被KILL了。

是谁这么暗箭伤人?操作系统给了我们杀死其他进程的能力,但自己被杀时,却连仇家都找不到。大概是怕冤冤相报何时了。

auditd

想要找到是谁干的,Linux下有一个比较厉害审计工具,auditd,他可以审计很多系统调用,包括kill。

看下如何配置:

1
2
~ # cat /etc/audit/rules.d/audit.rules
-a entry,always -F arch=b64 -S kill -k kill_signals

启动:

1
~ # service auditd restart

有可能启动不了,strace看了一下,发现日志目录没创建,补充一个:

1
~# mkdir -p /var/log/audit

可以通过ausearch去搜索刚才定义的kill_signals日志:

1
~ # ausearch -k kill_signals

但是我更喜欢看日志:

1
2
~ # tailf /var/log/audit/audit.log
type=SYSCALL msg=audit(1517390105.185:535): arch=c000003e syscall=62 success=yes exit=0 a0=4ea6 a1=9 a2=0 a3=7fff6cfb3e50 items=0 ppid=20482 pid=20527 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=447 comm="fantom" exe="/usr/bin/bash" key="kill_signals"

日志分析

上面的日志,KILL进程的,来自于:

1
comm="fantom" exe="/usr/bin/bash"

可以看成是一个名为 fantom 的脚本。

如果不清楚是哪个脚本,可以在系统里面搜索,谁的名字叫fantom,我之前看到过,所以我猜测应该是/etc/init.d/fantom。

验证

修改/etc/init.d/fantom,加了一个sleep 1000,过一会儿ps,看出了,是谁调用的fantom stop:

1
2
3
root 29386 0.0 0.0 113120 1496 ? S 17:40 0:00 /bin/bash /etc/cron.min/verify_mac.sh
root 29436 0.0 0.0 113120 1448 ? S 17:40 0:00 \_ /bin/bash /etc/init.d/fantom stop
root 29460 0.0 0.0 107892 616 ? S 17:40 0:00 \_ sleep 1000

看看脚本 /etc/cron.min/verify_mac.sh,其是放在cron min里面的,也就是每分钟调用一次。

这个文件verify_mac.sh,看样子应该是序列化校验什么的,比较现在的网口mac地址,如果和记录的不一致,就stop fantom:

1
2
3
4
[01/31/2018 05:40:01 PM] mac:fe:fc:fe:35:72:2cfe:fc:fe:99:ad:f0
[01/31/2018 05:40:01 PM] md5:f73272be0a85e2f95e5c94dc62da91ba
[01/31/2018 05:40:01 PM] md5file:verify_mac.md5
[01/31/2018 05:41:29 PM] raw md5: 3a63ac56c02ab0f21513ddb0cd3afec0 != now md5: f73272be0a85e2f95e5c94dc62da91ba, stop fantom

查出原因后,问清楚,测试的这台虚拟机,关机后添加了一块网卡(导致mac地址变化),但是忘记了两者有关联。