php - Laravel Queue con Supervisor, ejecutando pero no procesando trabajos
supervisord (2)
¡Sé que es viejo pero tuve exactamente el mismo problema hace aproximadamente 2 semanas y lo solucioné! (supervisor 3.0 aquí) El problema con mi cola era solo un trabajador. Cuando agrego 2 trabajadores más y vuelvo a leer / actualizar los archivos de cofig, todo funciona a la perfección. Así que trata de cambiar el número de trabajadores, esto puede ayudarte.
He configurado Laravel Queue usando la base de datos y he configurado Supervisor para que siga funcionando, sin embargo, deja de procesar la cola después de un tiempo.
Estoy usando Mail::queue para enviar correos electrónicos. Si hago SSH en el servidor y ejecuto php /home/my/path/to/artisan --env=production --timeout=240 queue:listen --tries=5 entonces funciona bien y los correos electrónicos se envían. Pero, obviamente, no quiero tener que SSH para procesar los correos electrónicos, quiero que la cola se ejecute las 24 horas del día, los 7 días de la semana, así que instalé un supervisor para gestionar esto. He editado mi archivo supervisord.conf para incluir el siguiente programa:
[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
Y cuando comienzo el programa funciona, mis correos electrónicos se envían. Sin embargo, después de algún tiempo (normalmente al día siguiente) los correos electrónicos no se envían. Reviso la base de datos y la tabla de trabajos se está llenando. Cuando SSH en el servidor y ejecuto el supervisorctl status obtengo:
laravel_queue RUNNING pid 21081, uptime 2 days, 23:18:51
Dice 2 días, ya que ha estado funcionando durante el fin de semana y no ha funcionado hoy (lunes). Claramente no se está ejecutando, entonces, ¿cómo puedo hacer que Supervord reconozca que no está ejecutándose y reiniciarlo?
Si lo reinicio manualmente con supervisorctl restart laravel_queue , porque no está ejecutando supervisor, no puedo detenerlo y parece que se cuelga hasta que presiono CTRL + C. En ese momento recibo un rastreo que no entiendo:
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
Al revisar el estado nuevamente, la cola está detenida, así que ejecuto supervisorctl start laravel_queue y obtengo el mismo bloqueo que cuando se ejecuta el reinicio, pero se inició a medida que los trabajos se procesan y se envían correos electrónicos. Si presiono CTRL + C nuevamente, obtengo el mismo rastreo que el anterior.
Iniciar sesión
He revisado el registro de laraqueue después de dejarlo durante la noche. Intenté enviar un correo electrónico esta mañana y la mesa de trabajo está sentada allí esperando el proceso. El registro está lleno de esto:
X-Powered-By: PHP/5.6.10^M
Content-type: text/html; charset=UTF-8^M
^M
Eso es. Sólo un montón de eso se repite.
He comprobado el registro del supervisor y solo informa el inicio exitoso de laravel_queue. Para completar el registro es:
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)
ACTUALIZAR
Después de actualizar el supervisor a la última versión, todavía tengo el mismo problema. Laraqueue.log tiene el mismo contenido que antes, nada útil. Sin embargo, el registro del supervisor tiene un poco más en él esta vez:
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)
Hubo un par de instancias en las que el supervisor recibió la solicitud de salida y la inició de nuevo, y luego el final del registro está arriba de donde detiene la cola, pero no lo vuelve a iniciar por algún motivo. He revisado el registro de laravel (en almacenamiento / logs) pero no hay nada allí durante ese tiempo.
Comprueba qué versión de Supervisor tienes. Se sabe que algunos administradores de paquetes se olvidan de actualizar Supervisor. Creo que su problema se solucionará actualizando Supervisor. Por ejemplo, v2.1 de Supervisor es de 2007 y todavía está en algunos paquetes.
La versión actual de Supervisor es v3.13 aunque algunos dicen (ver la referencia en la parte inferior) v3 es la última versión estable.
Compruebe qué versión de Supervisor está utilizando
[root@test supervisor]# yum list | grep supervisor
Compare la versión mostrada para: https://pypi.python.org/pypi/supervisor
Quitar e instalar (fácil de instalar es bueno)
[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
Actualizar:
Tómese un momento para mirar aquí, vale la pena ( http://ahmed.amayem.com/running-a-node-js-app-ghost-in-the-background-continuously-with-supervisor-supervisord/ ) . Aunque él está ejecutando node.js / ghost con Supervisor, ¡no creo que eso importe ya que todo se trata de Supervisor!
Refs: https://github.com/Supervisor/supervisor/issues/165
http://ahmed.amayem.com/woes-of-using-an-outdated-supervisord-to-run-a-node-js-app-ghost/