delay_job将不会重新启动

Question

调试延迟的作业而不重新启动的最佳方法是什么？

运行restart表示它正在重启处理，但是grepping则没有进程。

$ RAILS_ENV=production ruby script/delayed_job -n3 --pid-dir=/dem/pids/ restart
Warning: no instances running. Starting...
Warning: no instances running. Starting...
Warning: no instances running. Starting...

$ ps -aux | grep delay
produser    3471  0.0  0.0   7232   612 pts/4    S+   10:28   0:00 tail -f delayed_job.log
produser    4059  0.0  0.0  11740   928 pts/0    S+   10:32   0:00 grep --color=auto delay

$ RAILS_ENV=production ruby script/delayed_job -n3 --pid-dir=/dem/pids/ restart
Warning: no instances running. Starting...
Warning: no instances running. Starting...
Warning: no instances running. Starting...

在拖曳delay_job.log文件的同时，它仅显示处理正在重新启动并且以静默方式失败。

2017-02-01T10:48:04-0800: [Worker(delayed_job.0 host:app pid:6257)] worker started
2017-02-01T10:48:04-0800: [Worker(delayed_job.1 host:app pid:6267)] worker started

Answer 1

我找到了自己问题的答案。 如果有人在搜索中找到，请在此处登录。

如果发现自己处在相同的情况下，请尝试在前台 （而不是后台） 运行该进程

RAILS_ENV=production ruby script/delayed_job --pid-dir=/dem/pids/ run

输出为：

found unexpected end of stream while scanning a quoted scalar at line 165 column 14

谷歌搜索包括dj来源的结果： 处理程序中格式错误的yaml可能会使所有delay_job工作者崩溃

---

这是一个很好的线索。

• 如果您的处理程序/数据格式错误，则DJ会静默失败。
• 如果您在DJ中处理电子邮件，则可能会有大量处理程序列，因为如果有人转发电子邮件，则该线程将包括在内。 让人惊讶。

我做了什么 我向我们的电子邮件处理程序查询了delayed_jobs 。

结果如何？ 一份怪异的大规模处理程序的工作。

也可能只查询最长的列 。

删除作业并运行run命令后，它将正常开始处理。