Make php artisan queue:work a commands for queue job

I have two suggestions:

1. If your queue workers are dying, figure out the underlying cause
2. Review the Laravel docs for setting up Supervisor, or user another process monitor, to watch and restart queue workers as needed: https://laravel.com/docs/5.4/queues#supervisor-configuration

Thanks you dipasquo. that's what i am working on, I was just wonder if they have a quick fix for temporary.

I set up the queuing system with Supervisor for the first time a couple months ago; from what I recall it took me less than 2 hours. I think you should still find the underlying cause of your queue workers dying, but in the time you make a temporary quick fix I bet you'd be a long way to having the permanent solution (e.g. Supervisor) up and running.

Hi I follow the instruction in there and change my laravel-worker.conf to

[program:laravel-worker] process_name=%(program_name)s_%(process_num)02d command=php /var/www/analytic/artisan queue:work sqs --sleep=3 --tries=3 --daemon autostart=true autorestart=true user=root numprocs=2 redirect_stderr=true stdout_logfile=/var/www/analytic/worker.log

then i run the command codes :

sudo supervisorctl reread

sudo supervisorctl update

sudo supervisorctl start laravel-worker:*

Some how I check my htop and it doesn't have any queue:work running, Do i have to run the queue first and run the supervisor? Also I tried to run the php artisan queue:work & and kill it but the supervisor doesn't automatically restart the queue:work

Thanks

You do not have to run the queue worker first, supervisor will start it up when it's not running.

I compared what you posted to the contents of my supervisor config file - two difference stand out:

1. You're configuring it to run as user=root whereas I am using a non-root user; as long as your supervisord is running as root (which it looks like it is since you are sudoing) than this is probably not a problem...

2. You have configured your queue worker to use AWS SQS to manage the queue ; do you have SQS properly configured to do that, or did you intend to use a database for the queue jobs? Mine looks like:

command=php /path/to/app/artisan queue:work database --sleep=3 --tries=3

What's the output of supervisorctl status? You should see something like:

dipasquo@ip-10-0-0-157:/app$ sudo supervisorctl status
[sudo] password for dipasquo:
queue-worker:queue-worker_00   RUNNING   pid 2380, uptime 15:18:15
queue-worker:queue-worker_01   RUNNING   pid 2384, uptime 15:18:14

If you don't see that, do you see any complaints in /var/log/supervisor/supervisord.log?

Do you see artisan processes running?, e.g.

dipasquo@ip-10-0-0-157:~$ ps auwwx | grep artisan
www-data  2380  0.0  1.8 304552 38376 ?        S    May01   0:18 php /path/to/app/artisan queue:work database --sleep=3 --tries=3
www-data  2384  0.0  1.8 304552 38408 ?        S    May01   0:18 php /path/to/app/artisan queue:work database --sleep=3 --tries=3

Thanks you very much dipasquo

Turn out I had to change my code to

command=php /var/www/analytic/artisan queue:work database --sleep=3 --tries=3 --daemon

I wonder what is the benefit of running

numprocs= more than 1

Thanks you.

I suppose numprocs > 1 is in order to minimize latency, if you expect to introduce a heavy workload into the queue. Imagine you were going to queue 100 email notifications to be sent for a given event, it's a job that's likely bound by application layer constraints, not CPU or RAM, and so you could parallelize it across many queue workers.