Question

所有的独角兽工人都在默默地死去，没有任何迹象表明原因，我也找不到任何外部过程杀死他们的证据。我是诊断这种东西的新手，经过几个小时的研究，试验，并试图解决这个问题，我走到了尽头。

背景信息 - 它是一个Rails 4.1应用程序，Ruby 2.0，在Ubuntu 14.04服务器上运行nginx和unicorn。

unicorn.rb

working_directory "/home/deployer/apps/ourapp/current"
pid "/home/deployer/apps/ourapp/current/tmp/pids/unicorn.pid"
stderr_path "/home/deployer/apps/ourapp/current/log/unicorn.log"
stdout_path "/home/deployer/apps/ourapp/current/log/unicorn.log"

listen "/tmp/unicorn.ourapp.sock"
worker_processes 2
timeout 30

摘自unicorn.log（死前和重启后的最后一行）

I, [2016-08-28T19:54:01.685757 #19559]  INFO -- : worker=1 ready
I, [2016-08-28T19:54:01.817464 #19556]  INFO -- : worker=0 ready
I, [2016-08-29T09:19:14.818267 #30343]  INFO -- : unlinking existing socket=/tmp/unicorn.ourapp.sock
I, [2016-08-29T09:19:14.818639 #30343]  INFO -- : listening on addr=/tmp/unicorn.ourapp.sock fd=10
I, [2016-08-29T09:19:14.818807 #30343]  INFO -- : worker=0 spawning...
I, [2016-08-29T09:19:14.824358 #30343]  INFO -- : worker=1 spawning...

一些相关信息：

经过一段约8-20小时的时间，独角兽死了。
独角兽日志中没有记录错误。
我搜索了所有/var/log以查找已被杀死的进程的证据，并且只能找到一个在几天前被杀死的无关进程。
New Relic显示在最后一次随机关闭之前的内存使用量，使用大约400mb的ruby。它目前只有480mb，没有任何问题，所以我认为它不会受到内存限制。
与CPU使用情况相同......红宝石在死亡前徘徊在0.1％左右。
最后几次死亡是在半夜。唯一的请求来自New Relic和Linode Longview监控。
我们的production.log显示最后一个请求，然后作为New Relic的ping死亡。它Completed 200 OK in 264ms所以它似乎不是请求超时。
它也发生在暂存中，并且日志级别设置为debug，并且暂存日志中没有其他线索。

问题：

什么可能会杀死Unicorn工作人员不是内存管理器或关闭信号？
可能是OOM还是关闭信号，它被录制在某个我不看的地方，或者是因为某些原因没有被录制？
有没有办法更详细地捕捉到对Unicorn的哄骗？

我不知道从哪里开始，所以任何建议都会非常感激。

更新

正如所建议的那样，我使用strace来发现独角兽被一个旧的crontab（我知道我之前应该在那里检查过）所杀，这是由以前的开发人员添加的，它们每晚都要重启服务器。 stop命令工作，但启动命令失败。

我仍然不知道为什么我无法在我的日志搜索中找到任何内容，但是在将strace附加到主要的独角兽进程（使用类似strace -o /tmp/strace.out -s 2000 -fp <unicorn_process_id>之类的内容）后，strace日志以明确+++ killed by SIGKILL +++结束。我再次搜索了日志，这导致我进入了crontab。

根本原因可能与我的情况非常相关，但我真的很高兴我现在知道strace。

独角兽工人无缘无故地死去

0 个答案: