如何定位进程被kill

问题背景与现象

在某环境出现DataNode异常重启，且确认此时未从页面做重启DataNode的操作，需要定位是什么进程kill DataNode服务端进程。

原因分析

常见的进程被异常终止有2种原因：

Java进程OOM被Kill
一般Java进程都会配置OOM Killer，当检测到OOM会自动Kill，OOM日志通常被打印到out日志中，此时可以看运行日志（如DataNode的日志路径为 /var/log/Bigdata/hdfs/dn/hadoop-omm-datanode-主机名.log），看是否有OutOfMemory 内存溢出的打印。

被其他进程kill，或者人为kill。

排查DataNode运行日志（/var/log/Bigdata/hdfs/dn/hadoop-omm-datanode-主机名.log），是先收到“RECEIVED SIGNAL 15”再健康检查失败。即如下示例中DataNode先于 11:04:48被kill，然后过2分钟，于 11:06:52启动。

2018-12-06 11:04：48,433 | ERROR | SIGTERM handler | RECEIVED SIGNAL 15: SIGTERM | LogAdapter.java:69
2018-12-06 11:04:48,436 | INFO  | Thread-1 | SHUTDOWN_MSG:
/************************************************************
SHUTDOWN_MSG: Shutting down DataNode at 192-168-235-85/192.168.235.85
************************************************************/ | LogAdapter.java:45
2018-12-06 11:06:52,744 | INFO  | main | STARTUP_MSG:

以上日志说明，DataNode先被其他进程关闭，然后健康检查失败，2分钟后，被NodeAgent启动DataNode进程。

处理步骤

打开操作系统审计日志，给审计日志增加记录kill命令的规则，即可定位是何进程发送的kill命令。

操作影响

打印审计日志，会消耗一定操作系统性能，经过分析仅影响不到1%。
打印审计日志，会占用一定磁盘空间。该日志打印量不大，MB级别，且默认配置有老化机制和检测磁盘剩余空间机制，不会占满磁盘。

定位方法

在DataNode进程可能发生重启的所有节点，分别执行以下操作。

以root用户登录节点，执行service auditd status命令，确认该服务状态。
```
Checking for service auditd  running
```
如果该服务未启动，执行service auditd restart命令重启该服务（无影响，耗时不到1秒）
```
Shutting down auditd done
Starting auditd done
```
审计日志临时增加kill命令审计规则。

增加规则：

auditctl -a exit,always -F arch=b64 -S kill -S tkill -S tgkill -F a1!=0 -k process_killed

查看规则：

auditctl -l
当进程有异常被kill后，使用ausearch -k process_killed命令，可以查询kill历史。

a0是被kill进程的pid（16进制），a1是kill命令的信号量。

验证方法

从MRS页面重启该节点一个实例，如DataNode。
执行ausearch -k process_killed命令，确认是否有日志打印。

例如以下命令ausearch -k process_killed |grep “.sh” ，可以看到是hdfs-daemon-ada* 脚本，关闭的DataNode进程。