Laravel File d'attente avec le superviseur, en cours d'exécution mais pas de traitement des travaux
J'ai configuré Laravel File d'attente à l'aide de la base de données et j'ai configuré Supervisor pour qu'elle continue à fonctionner, mais il arrête de traiter la file d'attente après un certain temps.
J'utilise Mail::queue pour envoyer des e-mails. Si je me connecte au serveur et exécute php /home/my/path/to/artisan --env=production --timeout=240 queue:listen --tries=5 alors cela fonctionne bien et les e-mails sont envoyés. Mais évidemment, je ne veux pas avoir à SSH pour traiter les e-mails, je veux que la file d'attente fonctionne 24h/24 et 7j/7, j'ai donc installé un superviseur pour gérer cela. J'ai modifié mon fichier supervisord.conf pour inclure le programme suivant:
[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
Et lorsque je démarre le programme, cela fonctionne, mes e-mails sont envoyés. Cependant, après un certain temps (normalement le lendemain), les e-mails ne seront pas envoyés. Je vérifie la base de données et le tableau des emplois se remplit. Lorsque je me connecte au serveur et exécute supervisorctl status Je reçois:
laravel_queue RUNNING pid 21081, uptime 2 days, 23:18:51
Il dit 2 jours car il a fonctionné le week-end et ne fonctionne pas aujourd'hui (lundi). De toute évidence, il ne fonctionne pas, alors comment puis-je faire en sorte que supervord reconnaisse qu'il ne fonctionne pas et le redémarre?
Si je le redémarre manuellement avec supervisorctl restart laravel_queue, car il ne fonctionne pas, le superviseur ne peut pas l'arrêter et semble simplement se bloquer jusqu'à ce que j'appuie sur CTRL + C. À ce stade, j'obtiens un retraçage que je ne comprends pas:
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
Si je vérifie à nouveau l'état, la file d'attente est arrêtée, donc je lance supervisorctl start laravel_queue et j'obtiens le même blocage que lors de l'exécution du redémarrage, mais il a commencé lorsque les travaux sont traités et les e-mails envoyés. Si j'appuie à nouveau sur CTRL + C, j'obtiens le même retraçage que ci-dessus.
Journal
J'ai vérifié le journal de laraqueue après l'avoir laissé pendant la nuit. J'ai essayé d'envoyer un e-mail ce matin et la table de travail est juste assise là en attente de traitement. Le journal est juste plein de ceci:
X-Powered-By: PHP/5.6.10^M
Content-type: text/html; charset=UTF-8^M
^M
C'est tout. Juste beaucoup de choses qui se répètent.
J'ai vérifié le journal du superviseur et il ne fait que signaler le démarrage réussi de laravel_queue. Pour terminer, le journal est:
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)
METTRE À JOUR
Après avoir mis à jour le superviseur vers la dernière version, j'ai toujours le même problème. Le laraqueue.log a le même contenu qu'auparavant, rien d'utile. Cependant, le journal du superviseur contient un peu plus cette fois-ci:
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)
Il y a eu quelques cas où le superviseur a reçu la demande de sortie et l'a démarrée, puis la fin du journal est au-dessus de l'endroit où il arrête la file d'attente, mais ne la redémarre pas pour une raison quelconque. J'ai vérifié le laravel log (dans le stockage/logs) mais il n'y a rien dedans à cette époque.
Vérifiez la version de Supervisor dont vous disposez. Certains gestionnaires de packages oublient de mettre à jour Supervisor. Je pense que votre problème sera résolu en mettant à jour Supervisor. Par exemple, la version 2.1 de Supervisor date de 2007 et est toujours dans certains packages.
La version actuelle de Supervisor est la v3.13 bien que certains disent (voir référence en bas) que la v3 est la dernière version stable.
Vérifiez la version de Supervisor que vous utilisez
[root@test supervisor]# yum list | grep supervisor
Comparer la version montrée à: https://pypi.python.org/pypi/supervisor
Supprimer et installer (l'installation facile est agréable)
[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
Mettre à jour:
Veuillez prendre un moment pour regarder ici, cela en vaut la peine ( http://ahmed.amayem.com/running-a-node-js-app-ghost-in-the-background-continuously-with-supervisor -supervisord / ). Bien qu'il exécute node.js/ghost avec Supervisor, je ne pense pas que cela compte car il s'agit uniquement de Supervisor!
Réfs: https://github.com/Supervisor/supervisor/issues/165
http://ahmed.amayem.com/woes-of-using-an-outdated-supervisord-to-run-a-node-js-app-ghost/
Je sais que c'est vieux mais j'ai eu exactement le même problème il y a environ 2 semaines et je l'ai corrigé! (superviseur 3.0 ici) Le problème avec ma file d'attente n'était qu'un seul employé. Quand j'ajoute 2 autres travailleurs et relis/mets à jour les fichiers cofig, tout fonctionne comme un charme. Essayez donc de changer le nombre de travailleurs - cela peut vous aider.