带有Supervisor的Laravel Queue，正在运行但未处理作业

时间：2015-10-19 14:38:45

标签： php laravel supervisord

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

我正在使用Mail::queue发送电子邮件。如果我通过SSH连接到服务器并运行php /home/my/path/to/artisan --env=production --timeout=240 queue:listen --tries=5，那么它可以正常工作并发送电子邮件。但显然我不想使用SSH来处理电子邮件，我希望队列全天候运行，所以我安装了主管来管理它。我编辑了我的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日志（在存储/日志中），但那时候没有任何内容。

5 个答案:

答案 0 :(得分：3)

检查您拥有的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/

答案 1 :(得分：1)

我在Laravel 8和主管3中遇到了同样的问题。

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

import pandas as pd    
df = pd.DataFrame({'a':["",0,1,2,3]})
df['new_a'] = pd.to_numeric(df['a'], errors='coerce')
df['Aa'] = df['new_a'].apply(lambda x: np.nan if math.isnan(x) else (0 if x==0 else (OTHER CONDITION)))

希望对您有帮助。

答案 2 :(得分：1)

这对我有用：

[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

也运行@netdjw 所说的。 享受。

答案 3 :(得分：0)

我知道它已经很旧了，但是大约2周前我遇到了完全相同的问题，因此我将其修复！ （此处为主管3.0） 我的队列的问题只有一个工人。当我再添加2个工作程序并重新读取/更新cofig文件时，所有内容都像一个超级按钮。因此，请尝试更改工人数量-这可能会对您有所帮助。

答案 4 :(得分：0)

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

SUPERVISE=enable

SUPERVISE=enable

您可以通过以下方式检查工作进程是否正在运行

ps aux | grep artisan
相关问题
最新问题