Подтвердить что ты не робот

Очередь Laravel с Супервизором, работающая, но не работающая с заданиями

Я настроил Laravel Queue с помощью базы данных, и я настроил 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 днях, поскольку он работал в выходные и не работал сегодня (понедельник). Понятно, что это не работает, так как мне получить супервизор, чтобы узнать, что он не запущен и не перезапустил его?

Если я вручную перезагружу его с помощью 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)



UPDATE

После обновления супервизора до последней версии у меня все еще такая же проблема. 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 (в хранилищах/журналах), но в то время там ничего не было.

4b9b3361

Ответ 1

Проверьте, какая версия Supervisor у вас есть. Известно, что некоторые менеджеры пакетов забывают обновлять Supervisor. Я думаю, ваша проблема будет исправлена ​​путем обновления Supervisor. Например, v2.1 Supervisor - с 2007 года и все еще находится в некоторых пакетах.

Текущая версия Supervisor - v3.13, хотя некоторые говорят (см. ссылку внизу) v3 - последняя стабильная версия.

Проверьте, какую версию Supervisor вы используете

[[email protected] supervisor]# yum list | grep supervisor 

Сравните версию, показанную на: https://pypi.python.org/pypi/supervisor

Удалить и установить (простая установка проста)

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

Update:

Пожалуйста, найдите минутку, чтобы посмотреть здесь, это того стоит (http://ahmed.amayem.com/running-a-node-js-app-ghost-in-the-background-continuously-with-supervisor-supervisord/). Хотя он работает node.js/ghost с Supervisor, я не думаю, что это имеет значение, поскольку это все о Supervisor!

Refs: 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/

Ответ 2

Я знаю это старое, но у меня была точно такая же проблема около 2 недель назад, и я исправил это! (supervisor 3.0 здесь) Проблема с моей очередью была только у одного работника. Когда я добавляю еще 2 рабочих и перечитываю/обновляю файлы cofig, все работает как чудо. Поэтому попробуйте изменить количество работников - это может вам помочь.