谁杀了我的进程-从残缺的日志中脑补案发现场

2020年12月8日晚，现场同学联系我们，我们用到的对象存储MinIO又宕了，进程都没了，赶紧查是怎么回事。于是我和家银、至荣、忠迪又屁颠屁颠的和现场同学一起查问题。

问题描述

MinIO进程没了，大概是下午18点发现的。

排查方向

进程没了，无外乎是三种情况

MinIO自己进程宕了
操作系统把进程杀了，可以通过dmesg以及操作系统日志去排查
人为杀的，可以通过history命令查一下

问题分析

日志收集

进程如果宕了，按照上面的原因推理，应该从三方面收集日志。

MinIO日志

goroutine 6379292 [IO wait, 3 minutes]:
internal/poll.runtime_pollWait(0x7f3bba8ca000, 0x72, 0xffffffffffffffff)
	runtime/netpoll.go:203 +0x55
internal/poll.(*pollDesc).wait(0xc003c39b18, 0x72, 0x1000, 0x1000, 0xffffffffffffffff)
internal/poll/fd_poll_runtime.go:87 +0x45
internal/poll.(*pollDesc).waitRead(...)
internal/poll/fd_poll_runtime.go:92

rax    0xca
rbx    0x3506700
rcx    0xffffffffffffffff
rdx    0x0
rdi    0x3506848
rsi    0x80
rbp    0x7ffc0eee4c50
rsp    0x7ffc0eee4c08
r8     0x0
r9     0x0
r10    0x0
r11    0x286
r12    0xff
r13    0x0
r14    0x20986da
r15    0x0
rip    0x469f01
rflags 0x286
cs     0x33
fs     0x0
gs     0x0

dmesg日志
history日志
java进程

思维跳跃式的推理

首先可以告诉你，基于上面的日志是可以推断出大概的原因的，大家可以花10分钟试着推理一下，然后再往下看推理过程。

是操作系统杀了我的进程吗

从dmesg以及操作系统日志来看，应该不是操作系统把进程杀掉的。

是MinIO自我了断了吗

有这个可能性，但是从MinIO日志以及google还有MinIO官方issue都没有找到相应的信息，可能性较低。

是人为的吗

从十多年的经验来看，大部分问题是咱们人为的，一个广泛使用的成熟的开源或者商用项目，出低级问题的可能性较低，就算出低级问题，也是非常早时期就开始尝试的团队就遇到了。比如数据库出现了一些问题，大家会想是慢sql或者并发过大，或者是数据库本身没调优导致的，而不会想，呀，我发现了数据库的一个bug。

怎么找出人为的原因呢？通过history命令可以看到一些大家执行的命令。但是比较遗憾的是，服务器没有配置history记录命令执行的时间，而且也没有配置history -a；所以无法看到命令执行的时间。好在通过who看了一下目前登录的session,都是20点之后登录的，也就在其它session执行的命令应该已经记录到history日志中了。

见证奇迹的时刻到了

从history日志中可以看到

735 ps -ef | grep java
736 ps -ef | grep minio
737 jcmd 26247 Thread.print

以及正在运行的java进程

推理来咯

有人查找了一个java的进程和minio的进程信息
然后通过jcmd去看java线程

这三行平平无奇的日志在暗示着我们什么呢。这个26247应该就是java进程的id吧。但是你看一下，正在运行的两个java进程是3131和18984,而且它俩是从12月4号就开始运行着的，history后面也没有人杀java进程或者是启动新的java进程。莫非26247是MinIO的进程ID，有人用jcmd这个java的监控命令去对MinIO这个golang的程序进行监控分析？

那就验证一下吧，找一个MinIO的进程，然后执行

jcmd [MinIO pid] Thread.print

发现控制台输出以下日志

哈哈，是不是豁然开朗了，是不是觉得查出来90%了，别急，万一遇到跟上次那个只会说我没问题，我的程序是好的这样的友商一样的人，就不好说了。回想一下我们之前看到的有点奇怪的MinIO日志，我们再看一下，发现日志中又多了一堆这样的日志信息

r14    0x20986da
r15    0x0
rip    0x469f01
rflags 0x286
cs     0x33
fs     0x0
gs     0x0

每运行一次jcmd，MinIO日志中就多了一次这样的输出

这个是不是就比较石锤了，从细枝末节中还原出来了问题出现的场景，从日志来看也能吻合。

后记

我承认我有赌的成分。在排查这个问题时，脑子里分析仅有的这些信息，基于已有的信息的推理还是挺有意思的。

另外想和大伙说一句，做平台不容易啊，啥都能算到它头上。socket连接失败了也找，文件丢了也说是存储服务搞丢的。我们还不能像业界搞开源的同行一样，说google is your friend，我们要这么说，那就是甩锅，不配合团队间工作，没有服务意识。咱们在找别的团队之前，可以先适当分析一下原因，有个初步的判断，毕竟传递一次，信息就会丢失一些。

与君共勉。

本文分享自微信公众号 - 程序员阿水（gh_124d28263603）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

来源：oschina

链接：https://my.oschina.net/u/3828362/blog/4784675

标签

Minio

java