Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

deansatch's avatar

Supervisor queue:work failing

I set up a worker with supervisor on a site a while back which is supposed to send out emails on dates chosen by customers. It seems to have stopped working at some point as a couple of jobs in my database 'jobs' table were meant to go out today and didn't.

I checked the worker.log file and there are hundreds of lines saying things along the lines of:


[Illuminate\Database\QueryException]                                         
  SQLSTATE[HY000] [2002] Connection refused (SQL: select * from information_s  
  chema.tables where table_schema = homestead and table_name = site_settings)   
                                                                               
                                             
  [Doctrine\DBAL\Driver\PDOException]        
  SQLSTATE[HY000] [2002] Connection refused

my supervisor/conf.d/laravel-worker.conf file looks like this:


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

If I run "cd /var/www/site/" then "php artisan queue:work" from ssh the jobs go out as they should. Any ideas? It seems really tough to debug stuff like this. Also is there any way I can monitor this so that I don't have to rely on the unhappy customers letting me know an email never turned up

I was thinking that maybe the problem is caused by supervisor not restarting things after a server or database crash/reboot?

0 likes
8 replies
patrick591's avatar

You probably know this but when you modify your php code.. I think you have to restart your supervisor tasks. i.e. sudo supervisorctl stop laravel-worker:* sudo supervisorctl reread sudo supervisorctl update sudo supervisorctl start laravel-worker:*

Wondering if any code changed and the workers aren't aware. Either way I'd try the above commands if you didn't already.

burlresearch's avatar

I wouldn't run the command as user=root - I'd bet that there's something weird going on with the user permissions. Try and switch root for the user that owns your application, what user is returned by:

stat -c%U /var/www/site/artisan

deansatch's avatar

@BURLRESEARCH - That returns www-data which is the same user I use for setting all permissions on folders. It does work as root but it seems like when the DB has any sort of failure and reboots it just doesn't seem to restart the processes.

So if I type supervisorctl now I will see 3 processes RUNNING. But if I come back in a week or so, no doubt the DB will have had some issue and typing supervisorctl then will show them tasks as FAILED for exiting too quickly.

burlresearch's avatar

This doesn't sound like an issue with supervisor as much as it sounds like an issue with your database crashing. This probably shouldn't be happening.

Even in the event of the database going down temporarily - I can see that some jobs would fail - but supervisor ought to pick up OK and keep processing any new work.

There is pretty good explanation on how to deal with failed Jobs:

https://laravel.com/docs/5.7/queues#dealing-with-failed-jobs

I'd recommend using Horizon, instead, if you want a nice way to see what's going on:

https://laravel.com/docs/5.7/horizon

deansatch's avatar

@BURLRESEARCH - Yeah I fixed the dB issue so hopefully it won’t happen again.

But it wasn’t that the jobs were failing, after sql automatically reboots it just wouldn’t run the jobs...they were still sitting in the table. I had to do reread and update just to get it to start working properly again

burlresearch's avatar

Sorry bro, just trying to help.

I can't get away from the fact that the error is PDOException [2002] Connection refused - why would the database refuse a connection during the Job, but not from a Console command?

Something is different there - and that's the issue, it seems. By the sounds of it you have supervisor and your queue:worker setup OK.

  1. Does your queue worker call the same code path as the Console application?
  2. What does your crontab -l -u www-data look like? (It's calling your Job scheduler correctly?)

Again, my spidey-sense says it's something other than the queue worker...

Please or to participate in this conversation.