Laravel Queue with Supervisor，正在运行但不处理作业答案

【问题标题】：Laravel Queue with Supervisor, running but not processing jobsLaravel Queue with Supervisor，正在运行但不处理作业
【发布时间】：2016-01-17 23:14:40
【问题描述】：

我已经使用数据库设置了 Laravel 队列，并且我已经配置了 Supervisor 以使其保持运行，但是它会在一段时间后停止处理队列。

我正在使用Mail::queue 发送电子邮件。如果我通过 SSH 连接到服务器并运行 php /home/my/path/to/artisan --env=production --timeout=240 queue:listen --tries=5，那么它可以正常工作并发送电子邮件。但显然我不想通过 SSH 来处理电子邮件，我希望队列 24/7 运行，所以我安装了主管来管理它。我已经编辑了我的 supervisord.conf 文件以包含以下程序：

[program:laravel_queue]
command=php /home/my/path/to/artisan --env=production --timeout=240 queue:listen --tries=5
autostart=true
autorestart=true
logfile=/var/log/laraqueue.log

当我启动它的程序时，我的电子邮件就会发送。但是一段时间后（通常是第二天），电子邮件不会发送。我检查了数据库，作业表正在填满。当我通过 SSH 连接到服务器并运行 supervisorctl status 时，我得到：

laravel_queue  RUNNING    pid 21081, uptime 2 days, 23:18:51

它说的是 2 天，因为它在周末运行，今天（星期一）不工作。显然它没有运行，那么我如何让 supervisord 识别它没有运行并重新启动它？

如果我使用supervisorctl restart laravel_queue 手动重新启动它，因为它没有运行，主管无法停止它，并且似乎一直挂起，直到我按下 CTRL + C。此时我得到一个我不明白的回溯：

Traceback (most recent call last):
  File "/usr/bin/supervisorctl", line 6, in <module>
    main()
  File "/usr/lib/python2.6/site-packages/supervisor/supervisorctl.py", line 598, in main
    c.onecmd(" ".join(options.args))
  File "/usr/lib/python2.6/site-packages/supervisor/supervisorctl.py", line 86, in onecmd
    return func(arg)
  File "/usr/lib/python2.6/site-packages/supervisor/supervisorctl.py", line 467, in do_restart
    self.do_stop(arg)
  File "/usr/lib/python2.6/site-packages/supervisor/supervisorctl.py", line 433, in do_stop
    result = supervisor.stopProcess(processname)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.6/site-packages/supervisor/options.py", line 1309, in request
    errcode, errmsg, headers = h.getreply()
  File "/usr/lib64/python2.6/httplib.py", line 1064, in getreply
    response = self._conn.getresponse()
  File "/usr/lib64/python2.6/httplib.py", line 990, in getresponse
    response.begin()
  File "/usr/lib64/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python2.6/httplib.py", line 349, in _read_status
    line = self.fp.readline()
  File "/usr/lib64/python2.6/socket.py", line 433, in readline
    data = recv(1)
KeyboardInterrupt

再次检查状态报告队列已停止，因此我运行supervisorctl start laravel_queue 并得到与运行重新启动时相同的挂起，但它已在处理作业和发送电子邮件时启动。如果我再次按 CTRL + C，我会得到与上面相同的回溯。

日志

我已经检查了 laraqueue 日志，它是在过夜后留下的。今天早上我试图发送一封电子邮件，而工作表只是坐在那里等待处理。日志就是这样：

X-Powered-By: PHP/5.6.10^M
Content-type: text/html; charset=UTF-8^M
^M

就是这样。只是重复了很多。

我检查了主管日志，它只报告 laravel_queue 的成功启动。为了完成，日志是：

2015-10-21 14:25:24,997 INFO /var/tmp/supervisor.sock:Medusa (V1.1.1.1) started at Wed Oct 21 14:25:24 2015
    Hostname: <unix domain socket>
    Port:/var/tmp/supervisor.sock
2015-10-21 14:25:25,099 CRIT Running without any HTTP authentication checking
2015-10-21 14:25:25,107 INFO daemonizing the process
2015-10-21 14:25:25,108 INFO supervisord started with pid 3407
2015-10-21 14:25:25,115 INFO spawned: 'laravel_queue' with pid 3409
2015-10-21 14:25:26,729 INFO success: laravel_queue entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

更新

将主管更新到最新版本后，我仍然遇到同样的问题。 laraqueue.log 的内容和以前一样，没什么用处。但是这次主管日志中包含更多内容：

2015-10-22 10:19:59,454 CRIT received SIGTERM indicating exit request
2015-10-22 10:19:59,454 INFO waiting for laravel_queue to die
2015-10-22 10:19:59,460 INFO stopped: laravel_queue (terminated by SIGTERM)
2015-10-22 10:19:59,460 INFO received SIGCLD indicating a child quit
2015-10-22 10:26:02,019 CRIT Supervisor running as root (no user in config file)
2015-10-22 10:26:02,085 CRIT Server 'inet_http_server' running without any HTTP authentication checking
2015-10-22 10:26:02,092 INFO daemonizing the supervisord process
2015-10-22 10:26:02,093 INFO supervisord started with pid 17268
2015-10-22 10:26:03,105 INFO spawned: 'laravel_queue' with pid 17269
2015-10-22 10:26:04,107 INFO success: laravel_queue entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2015-10-22 10:37:22,157 WARN received SIGTERM indicating exit request
2015-10-22 10:37:22,157 INFO waiting for laravel_queue to die
2015-10-22 10:37:22,163 INFO stopped: laravel_queue (terminated by SIGTERM)

有几个主管接收退出请求并启动它的实例，然后日志的结尾在它停止队列的位置之上，但由于某种原因没有再次启动它。我检查了 laravel 日志（在 storage/logs 中），但在那段时间里什么都没有。

【问题讨论】：

它显然仍在运行，但发生了一些事情 - 并且没有抛出退出代码供主管处理。您的/var/log/laraqueue.log 文件中是否有任何提示？
之前使用 SMTP 邮件设置填充日志时出现另一个错误，我已经解决了这个问题（改用本地 MAIL 功能）。我已经清除了日志，正在等待下次停止时是否有任何错误。希望明天能有所收获。
当您 ssh 并以 root 身份运行 ./artisan queue:listen .... 时它是否有效？除非您指定用户名，否则主管会以 root 身份运行作业，这可能会产生副作用。
我只使用 root 和 SSH，我们没有任何其他帐户。是的，运行 php artisan queue:listen 工作正常。
您找到解决问题的方法了吗？我在运行主管 v2.1-9 的同时也遇到了类似的问题。我有点害怕删除和安装，因为我可能会删除 conf 中编写的队列程序。

标签： php laravel supervisord

【解决方案1】：

我对 Laravel 8 和 supervisor 3 有同样的问题。

我通过重新运行这些命令解决了我的问题：

sudo supervisorctl stop all

sudo supervisorctl reread

sudo supervisorctl update

sudo supervisorctl start all

希望对你有帮助。

【讨论】：

谢谢。我对 Laravel 8 也有同样的问题，但能够使用您的解决方案使其正常工作
对我来说就像一个魅力，谢谢@netdjw
在 CentOS 8 Laravel 8 上完美运行
这是一个类似于重启supervisor的临时修复，它会在一段时间后再次停止。

【解决方案2】：

检查您拥有的 Supervisor 版本。众所周知，一些包管理器会忘记更新 Supervisor。我认为您的问题将通过更新主管来解决。例如，Supervisor v2.1 是从 2007 年开始的，并且仍在某些软件包中。

Supervisor 的当前版本是 v3.13，尽管有人说（参见底部的参考资料）v3 是最后一个稳定版本。

检查你使用的 Supervisor 版本

[root@test supervisor]# yum list | grep supervisor

比较显示的版本：https://pypi.python.org/pypi/supervisor

删除和安装（简单安装很好）

[root@test ~]$ yum remove supervisor
[root@test ~]$ wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py -O - | sudo python
[root@test ~]$ sudo easy_install supervisor
Searching for supervisor
Reading https://pypi.python.org/simple/supervisor/
Best match: supervisor 3.0

更新：

请花点时间看看这里，非常值得 (http://ahmed.amayem.com/running-a-node-js-app-ghost-in-the-background-continuously-with-supervisor-supervisord/)。尽管他正在与 Supervisor 一起运行 node.js/ghost，但我认为这并不重要，因为这都是关于 Supervisor 的！

参考： https://github.com/Supervisor/supervisor/issues/165

http://ahmed.amayem.com/running-a-node-js-app-ghost-in-the-background-continuously-with-supervisor-supervisord/

http://ahmed.amayem.com/woes-of-using-an-outdated-supervisord-to-run-a-node-js-app-ghost/

【讨论】：

我确实在运行 v2.1。我已经使用上面的命令安装了主管，我需要做任何事情让它在重新启动时自动启动吗？
我不得不重建配置，因为有很多差异
我会确保它明天早上还在运行，如果是，我会接受你的回答。
@Styphon 我更新了我的答案。所以我认为我们至少走在正确的道路上。我添加的 URL 有关于自动重启重启的很棒的说明
似乎没有解决问题。今天早上没有处理队列。我没有时间查看日志 atm，但稍后会检查它们。

【解决方案3】：

我知道它已经过时了，但大约 2 周前我遇到了完全相同的问题，我已经解决了！（这里是主管 3.0）我的队列的问题只有一名工人。当我再添加 2 个工作人员并重新读取/更新配置文件时，一切都像魅力一样。所以试着改变工人的数量——这可能会对你有所帮助。

【讨论】：

在主管配置文件中（您可以在 etc/supervisor/conf.d 目录中找到它们）您应该更改参数“numprocs”，然后运行 supervisorctl reread & update
感谢您的信息
@MilenaSchmidt 我解决了改进进程数的问题。我的问题是：你知道为什么这个解决方案有效吗？
@GiacomoM 很高兴它有帮助 :) 我不知道为什么会这样。我的猜测是，当一个工人死亡时，没有其他工人可以帮助第一个工人重新启动。当您有多个选项时，该选项是可能的。但正如我所说 - 我不确定这是否属实。我没有在任何地方找到我的问题的答案，所以我只是尝试了一切来完成这项工作 - 最终成功了。

【解决方案4】：

这对我有用：

[program:queue-worker]
process_name=%(program_name)s_%(process_num)02d
command=php {project_directory}/artisan queue:work
autostart=true
autorestart=true
user=root
numprocs=1
redirect_stderr=true
stdout_logfile= {project_directory}/worker.log

在我的 ubuntu 服务器上，我的队列工作文件在这里：

/etc/supervisor/conf.d/queue-worker.conf

还运行@netdjw 所说的内容。享受吧。

【讨论】：

【解决方案5】：

这个问题遇到了我的情况，主管队列进程正在运行但不处理作业，问题是您需要设置一个环境变量来启用它（如果它已经在后台运行）。

SUPERVISE=enable

您可以检查工作进程是否正在运行

ps aux | grep artisan

【讨论】：