我正在尝试设置队列用于日志存储、电子邮件发送和其他任务。
我决定使用beanstalkd和supervisor来控制作业队列的执行。我用composer安装了pda/pheanstalk ~2.0，在app/config/queue.php上进行了正确的设置，编写了Queue类并尝试执行任务。
这是一个例子，它是一个登录日志：
Auth::attempt(array(
'email' => $email,
'password' => $password
));
if (Auth::check()) {
$debounce = Carbon::now()->addSeconds(10);
Queue::later($debounce, 'SaveAcessLog', array('user' => Auth::id(), 'ip' => Request::getClientIp()));
}
因此，作为主管，我遵循了本教程。安装后，我按照每个步骤进行操作，并确保laravel_queue.conf也是run_queue.sh文件可执行。
问题是我无法执行任何任务。当我测试sudo supervisorctl时，我获得：
laravel_queue FATAL Exited too quickly (process log may have details)
访问/var/log/supervisor/supervisord.log上的supervisord日志文件显示：
2015-04-02 20:16:57,251 INFO supervisord started with pid 1269
2015-04-02 20:16:58,254 INFO spawned: 'laravel_queue' with pid 1316
2015-04-02 20:16:58,277 INFO exited: laravel_queue (exit status 127; not expected)
2015-04-02 20:16:59,279 INFO spawned: 'laravel_queue' with pid 1525
2015-04-02 20:16:59,287 INFO exited: laravel_queue (exit status 127; not expected)
2015-04-02 20:17:01,294 INFO spawned: 'laravel_queue' with pid 1753
2015-04-02 20:17:01,303 INFO exited: laravel_queue (exit status 127; not expected)
2015-04-02 20:17:04,658 INFO spawned: 'laravel_queue' with pid 1808
2015-04-02 20:17:04,668 INFO exited: laravel_queue (exit status 127; not expected)
2015-04-02 20:17:05,669 INFO gave up: laravel_queue entered FATAL state, too many start retries too quickly
所以，如果我尝试php artisan queue:work，任务就会被执行！我的主管设置缺少什么？
备注
我愿意用一些不同的东西来监督，以防它更简单或更有效。
检查主管startsecs=0是否有帮助。主管文件
我的配置：
[program:myqueue]
#command=php artisan queue:work --daemon --sleep=10 --verbose
command=php artisan queue:work --daemon --sleep=90 --tries=1 -vvv
## --timeout=0 --tries=0
#user=user
directory=/usr/share/nginx/laravel
stdout_logfile=/usr/share/nginx/laravel/app/storage/logs/myqueue_supervisord.log
redirect_stderr=true
autostart=true
startsecs=0
#autorestart=false
#startretries=0
#exitcodes=1
我知道这是一个老问题，但在我的supervisor配置中使用artisan queue:listen更幸运，这样它就不会一直启动和停止进程，但如果由于某种原因停止，应该重新启动。
更新
这似乎不是最好的解决方案，我发现它大部分时间都会运行队列。然而，如果有很长一段时间没有工作要处理，除非主管被告知重新开始工作，否则新的工作似乎不会得到处理。
更多更新
我现在有一个类似于以下的配置：
[program:worker]
process_name=%(program_name)s_%(process_num)02d
command=php artisan queue:work --sleep=3 --tries=3 --daemon
autostart=true
autorestart=true
numprocs=8
redirect_stderr=true
startretries=10
stdout_logfile=/dir/logs/worker.log
它似乎运行良好，而且很长时间没有故障。