进程无故被kill，非OOM，是病毒

现象

---

我的一个进程，是由crontab定时任务管理的，每天早上启动，晚上自动退出。

已经在服务器上稳定运行了几个月。

但是今天发现系统不太对，下游的服务不动作了，一查原因，原来的我的进程退出了。

没有看到有core或者异常日志。

为了先保证系统正常运行，手动启动它，结果刚运行1分钟左右，看到如下输出：

[1]  + 16957 killed     ./a.out

数次重启都被干掉了。

问题如此严重，需要好好查一下子。

定位

---

OOM

进程被kill掉，如果不是有进程主动为之，那就是被操作系统干掉了。

操作系统干掉一个进程，一般情况下是因为该进程占用了太大的内存，系统资源不够用了，才用kill掉它。

这种情况下，系统会记录日志，称为OOM（out of memory），可通过以下指令查看：

# 查看最后几条dmesg日志，-T表示打印正常的时间戳
dmesg -T | tail

结果没有看到进程相关的报错。

而且我的进程占用的内存确实不足以触发OOM，毕竟已经正常运行了一段时间，而且这个服务器上也没有新进程在跑。

应该不是系统把它干掉了。

进程崩溃

---

难道进程自己崩溃了？

打开内核转储，在当前终端运行程序：

# 打开内核转储
ulimit -c unlimited

# 启动程序
./a.out

过了1分钟左右，还是被kill了，且没有core文件产生。

所以也并非进程自己崩溃了。

病毒-bash

---

这个时候，听同事说他也遇到过进程被kill掉的情况，而且初步定位是由于病毒导致的。

虽然不是同一台服务器，但是局域网内，病毒传播，那是极其可能的。

于是开始检查：

• top 观察可疑进程，未发现（同事的机器，top可以看到有个-bash进程占用cpu高达300%，4核机器）

• htop 观察是否有-bash，还真有一个，但cpu和内存都是0

• 

• 锁定它的pid，查看进程位置：ls -l /proc/${pid}/，得到如下结果：

• 进入目录查看，看着果然像病毒（这个可以跟一台正常机器对比一下，正常机器是没有这些东西的）

• 查看定时任务，发现果然会自动拉起它！

好了，确认了病毒，有清理一下：

• 杀掉bash进程：kill -9 ${pid}
• 删除bash相关文件和文件夹
• 删除crontab任务：crontab -r
• 必要时重启机器

经过以上操作，业务进程可以正常运行，病毒也得到了清理。

小结

---

大多数情况下，业务进程被kill都是系统干的，查看dmesg可以得到有用的信息。

如果常规方法查找不到原因，就要结合网络环境来查看了。

当网络暴露在外网下时，就很有可能被病毒感染，这时也可能发生一些看似不可能的事情。