带有主管的 Laravel 队列，运行但不处理作业
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/33217269/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Laravel Queue with Supervisor, running but not processing jobs
提问by Styphon
I have set up Laravel Queue using the database and I've configured Supervisor to keep it running, however it stops processing the queue after a while.
我已经使用数据库设置了 Laravel 队列，并且我已经配置了 Supervisor 以使其保持运行，但是它会在一段时间后停止处理队列。
I'm using Mail::queueto send e-mails. If I SSH into the server and run php /home/my/path/to/artisan --env=production --timeout=240 queue:listen --tries=5then it works fine and the e-mails send. But obviously I don't want to have to SSH in to process the e-mails, I want the queue running 24/7 so I installed supervisor to manage this. I have edited my supervisord.conf file to include the following program:
我正在使用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
And when I start the program it works, my e-mails send. However after some time (normally the next day) the e-mails wont send. I check the database and the jobs table is filling up. When I SSH into the server and run supervisorctl statusI get:
当我启动程序时，它会工作，我的电子邮件会发送。但是一段时间后（通常是第二天），电子邮件不会发送。我检查了数据库，工作表正在填满。当我通过 SSH 连接到服务器并运行时，supervisorctl status我得到：
laravel_queue RUNNING pid 21081, uptime 2 days, 23:18:51
It's saying 2 days as it's been running over the weekend and not working today (Monday). Clearly it's not running, so how do I get supervisord to recognise that it's not running and restart it?
它说 2 天，因为它在周末运行并且今天（星期一）不工作。显然它没有运行，那么我如何让主管识别它没有运行并重新启动它？
If I manually restart it with supervisorctl restart laravel_queue, because it's not running supervisor can't stop it and just seems to hang until I press CTRL + C. At which point I get a traceback that I don't understand:
如果我用 手动重新启动它supervisorctl restart laravel_queue，因为它没有运行，supervisor 无法停止它并且似乎挂起直到我按下 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
Checking the status again reports the queue as stopped, so I run supervisorctl start laravel_queueand I get the same hang as when running restart, but it has started as the jobs are processed and e-mails sent. If I press CTRL + C again I get the same traceback as above.
再次检查状态报告队列已停止，因此我运行supervisorctl start laravel_queue并获得与运行重新启动时相同的挂起，但它已在处理作业和发送电子邮件时启动。如果我再次按 CTRL + C，我会得到与上面相同的回溯。
Log
日志
I've checked the laraqueue log after leaving it over night. I tried to send an e-mail this morning and the job table is just sitting there waiting to process. The log is just full of this:
我在离开它过夜后检查了 laraqueue 日志。我今天早上试图发送一封电子邮件，工作表就坐在那里等待处理。日志中充满了这个：
X-Powered-By: PHP/5.6.10^M
Content-type: text/html; charset=UTF-8^M
^M
That's it. Just lots of that being repeated.
就是这样。只是重复了很多。
I've checked the supervisor log and it just reports the successful start of laravel_queue. For completion the log is:
我检查了主管日志，它只是报告 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)
UPDATE
更新
After updating supervisor to the latest version, I'm still having the same issue. The laraqueue.log has the same content as before, nothing useful. However the supervisor log has a little more in it this time:
将 supervisor 更新到最新版本后，我仍然遇到同样的问题。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)
There was a couple instances of supervisor receiving the exit request and starting it back up, and then the end of the log is above where it stops the queue, but doesn't start it again for some reason. I've checked the laravel log (in storage/logs) but there's nothing in there for around that time.
有几个主管接收退出请求并重新启动它的实例，然后日志的结尾在它停止队列的位置上方，但由于某种原因没有再次启动它。我已经检查了 laravel 日志（在存储/日志中），但在那段时间里没有任何东西。
回答by NickNo
Check what version of Supervisor you have. Some package managers have been known to forget to update Supervisor. I think your problem will be fixed by updating Supervisor. For example v2.1 of Supervisor is from 2007 and is still in some packages.
检查您拥有的 Supervisor 版本。众所周知，一些包管理器会忘记更新 Supervisor。我认为您的问题将通过更新主管来解决。例如，Supervisor 的 v2.1 是 2007 年的，并且仍在某些软件包中。
Current version of Supervisor is v3.13 though some say (see reference at bottom) v3 is the last stable version.
Supervisor 的当前版本是 v3.13，尽管有人说（参见底部的参考）v3 是最后一个稳定版本。
Check what version of Supervisor you are using
检查您使用的是哪个版本的 Supervisor
[root@test supervisor]# yum list | grep supervisor
Compare version shown to: https://pypi.python.org/pypi/supervisor
比较显示的版本：https: //pypi.python.org/pypi/supervisor
Remove and Install (easy install is nice)
删除和安装（简单安装很好）
[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
Update:
更新：
Please take a moment to look here, it's well worth it ( http://ahmed.amayem.com/running-a-node-js-app-ghost-in-the-background-continuously-with-supervisor-supervisord/). Though he is running node.js/ghost with Supervisor, I don't think that matters since this is all about Supervisor!
请花点时间看看这里，它非常值得（http://ahmed.amayem.com/running-a-node-js-app-ghost-in-the-background-continuously-with-supervisor-supervisord/） . 尽管他与 Supervisor 一起运行 node.js/ghost，但我认为这并不重要，因为这完全是关于 Supervisor 的！
Refs: https://github.com/Supervisor/supervisor/issues/165
参考：https: //github.com/Supervisor/supervisor/issues/165
http://ahmed.amayem.com/woes-of-using-an-outdated-supervisord-to-run-a-node-js-app-ghost/
http://ahmed.amayem.com/woes-of-using-an-outdated-supervisord-to-run-a-node-js-app-ghost/
回答by Milena Schmidt
I know it's old but I had exactly same problem about 2 weeks ago and I fixed it! (supervisor 3.0 here) The problem with my queue was only one worker. When I add 2 more workers and reread/update cofig files everything works like a charm. So try to change number of workers - this may help you.
我知道它很旧，但大约 2 周前我遇到了完全相同的问题，我修复了它！（此处为主管 3.0）我的队列的问题是只有一名工人。当我再添加 2 个工人并重新读取/更新配置文件时，一切都像魅力一样。所以尝试改变工人的数量——这可能对你有帮助。
