是谁杀了我?

今天遇到的一个问题,记录一下。

起因是同事告诉我有两台机器上面的 node-exporter 挂掉了。

收到工单,来活了

我去看了下,确实挂了,这个进程是跑在 systemd 上的,就去 journalctl 看了下日志,发现日志很神奇:

观察最后三行,发现这个进程实际上是启动成功了,都打出来 Succeeded 了,但是之后立即退出了。

为什么会这样呢?我先查了下内存,发现用的一直很低,也没有 OOM 日志,所以应该不是 OOM。机器的 CPU 和磁盘其他指标都正常,应该不是硬件问题。

我不在 systemd 下面跑,直接在 shell 上跑这个进程,发现是一切正常的。这说明不是这个进程自己退出的,可能是 systemd 的问题,或者被其他什么东西干掉了。

既然这个进程没有自己退出,其他人要想停止它的话,只可能是给他发送信号。所以接下来我用 killsnoop (BPF 写的一个程序)看下这个是谁给我的进程发了信号,发送的是什么信号。

下面是启动日志,根据 pid 可以看到上面 killsnoop 显示出来,谁给这个进程发送了信号

可以看到,正是 systemd 给它发送了 15 和 18 信号。15 是 SIGTERM,应该正是这个信号结束了我的进程。

那么为什么 systemd 刚启动就要给我发这个信号呢?我想到的一种情况是进程启动之后 fork 了一份,parent process 退出了,于是 systemd 就把剩下的进程都杀了。但是考虑到其他机器一样的配置运行是正常的,并且 node-exporter 据我所知没有这种 fork 的逻辑,所以不太可能是这种情况。但是我决定还是验证一下,这里我用 execsnoop 来检查。这个 eBPF 程序可以看到机器上跑的所有命令(spawn 的进程历史)。

发现一个 systemctl stop node-exporter 命令

好家伙,没看到 node-exporter fork,却看到一个诡异的 systemctl stop node-exporter,原来有人在暗算我。

这个命令的父进程是 pid=177579,用 pstree 看看这个家伙是谁:

pstree

是个 bash 而且没有参数,是挂在 sudo su 下面的,看起来是有人 ssh 上来跑了个 systemctl stop node-exporter 就跑了。

systemctl status <pid>

strace 看看这个 bash 在干嘛:

strace 看看这个 bash 在干嘛

果然,就是 sleep 1s 然后开始杀我,不断循环。

干掉这个 bash,问题解决。

至于为啥会有人搞这么东西在上面,问了下,是野路子。



是谁杀了我?”已经有7条评论

  1. BCC这个东西太酷了,研究一下。

    >> 至于为啥会有人搞这么东西在上面,问了下,是野路子。

    好奇

  2. 真羡慕这种能把一个问题查到底,我们更多的是发现进程挂了,是不是OOM,如果不是几乎就没有下文了。能查到进程不在了,然后启动就是合格运维了。(怀疑我们的node-exporter挂掉有没有监控)。killsnoop execsnoop这些工具在小公司几乎没人知道,就算知道也没人会用,羡慕这种技术氛围

    • 我最近也在学 eBPF 相关的内容,这里的工具应该在《BPF 之巅》或者《性能之巅》里面会有介绍?看文章里的链接,execsnoop 这个工具也是来自这两本书的作者 Brendan Gregg 的 perf-tools 项目。这些书值得看一下

Leave a comment

您的电子邮箱地址不会被公开。 必填项已用 * 标注