Супервизор работает на фоне, но рабочие места сразу сбой

Question

Я успешно установил supervisor (CentOS release 6.6) в очередь beanstalk и он работал до этого, но после изменения пароля он больше не работает. Я сделал это (настройка), как root пользователем, но теперь, когда я добавить работу в queue он терпит неудачу и после трассировки доступна в файле журнала:

2014-12-03 00:45:36,017 INFO RPC interface 'supervisor' initialized 
2014-12-03 00:45:36,017 CRIT Server 'unix_http_server' running without any HTTP authentication checking 
2014-12-03 00:45:36,017 INFO daemonizing the supervisord process 
2014-12-03 00:45:36,017 INFO supervisord started with pid 31309 
2014-12-03 00:45:37,022 INFO spawned: 'queue' with pid 31317 
2014-12-03 00:45:38,023 INFO success: queue entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 

Сейчас supervisord.conf содержит следующую конфигурацию:

[unix_http_server] 
file=/tmp/supervisor.sock ; (the path to the socket file) 

[supervisord] 
logfile=/tmp/supervisord.log 
logfile_maxbytes=50MB 
logfile_backups=10 
loglevel=info 
pidfile=/tmp/supervisord.pid 
nodaemon=false 
minfds=1024 
minprocs=200 

[rpcinterface:supervisor] 
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface 

[supervisorctl] 
serverurl=unix:///tmp/supervisor.sock 

[program:queue] 
command=/usr/local/bin/php artisan queue:listen --tries=3 --timeout=86400 --sleep=60 

directory=/home/***/www/*** // Real path removed for this question 
autostart=true 
autorestart=true 
redirect_stderr=true 

Я пробовал все, как мог, перезапустил program и несколько раз перезагрузил supervisor, но не повезло. Что я могу сделать теперь, чтобы заставить его работать снова?

Обновление: Если я запустил php artisan queue:work с терминала вручную, то он работает на переднем плане.

Answer 1

Попробуйте

$ ps aux | grep artisan # get artisan PID 
$ sudo kill -2 <PID> 
$ ps aux | grep artisan # verify artisan has shutdown properly - if not use kill -9 in previous step 

Иногда supervisorctl имеет проблемы выключая процессы. Возможно, это связано с тем, что процесс не прослушивает SIGINT/SIGTERM или потому, что процесс зависает. В любом случае kill -9 должен грубой силой убить его, а затем вы можете использовать supervisorctl start program