Framework: [5.1] [5.2] queue:listen and queue:work not working on windows

[waylaidwanderer]

I can't figure out why this is happening. I'm am running redis-cli monitor to check for output, and while calling $this->dispatch(JOB) works (I can see the job being RPUSHed), neither running php artisan queue:listen or php artisan queue:work appears to be doing anything in redis (no change in the monitored output).

There is no output for php artisan queue:work before it terminates (or for queue:listen before I terminate it).

I've tried specifying the connection with php artisan queue:listen/work redis but this doesn't help either.

The above description was for redis, but using the database driver has the same issue. It's inserted in the database correctly, but is never processed (attempts is always 0).

I tried upgrading to 5.2 but with the same result. I used php artisan make:job ClassName --queued in 5.1 to create the command. In 5.2 I've removed SelfHandling from the class as well.

One other thing to note, it works fine when I set QUEUE_DRIVER=sync in .env. The queue used is default (i.e. I didn't specify a different queue).

[GrahamCampbell]

I can't replicate. I use redis in production, and I'm pretty sure Taylor uses database, and we both have no issues.

[waylaidwanderer]

Might be worth to note that I just tried it on my Debian 8 VPS (Laravel 5.1) which works, but still does not work on my Windows 10 computer. Is there anything which would prevent the queue from working depending on what OS the script is running from?

[GrahamCampbell]

That's very likely. The code we have is OS specific. Ping @taylorotwell.

[GrahamCampbell]

I've updated the issue title.

[zho]

ping @GrahamCampbell @taylorotwell

not working in homestead as well, i use database driver, and the job is not processed... even after i run the command line, the job still there...

laravel [5.1] homestead 0.3.3 @

[IDTIMW]

I have the same problem.

[gmatkowski]

Also, same problem

[aiddroid]

If you specified the connection or the queue when you add the job,you should run the listen or work command with connection and --queue,examples here:
php artisan queue:listen database --queue emails

[taytus]

Same problem. Jobs are added to the jobs table but they are never excecuted

[brazenvoid]

Same problem. Half of our dev team is on windows.

[ismailcaakir]

Aynı sorunu bende yaşıyorum. Laravel 5.3 ile tabloya veri ekliyorum fakat o verileri queue:listen ile çalıştıramıyorum.

[grepollo]

Any updates on this issue, i'm having this problem too. thanks.

[themsaid]

@grepollo on Windows? Laravel 5.3?

[taytus]

Haven't tested on 5.3, I had issues on 5.2

On Thu, Oct 13, 2016 at 9:15 AM, Mohamed Said [email protected]
wrote:

@grepollo https://github.com/grepollo on Windows? Laravel 5.3?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/laravel/framework/issues/11714#issuecomment-253525757,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAI9MyQtr2S5H21Jc8BnP3Syx98D-hfLks5qzj0dgaJpZM4G_XWs
.

[gboor]

I just ran into the same issue, but I knew for sure it worked before... so I did some digging and found out that the queue:work command does not return ANY errors to the console. In my case I first did not have Redis running and after that there was a problem serializing a model, because a value was not available.

Both errors showed up on the laravel.log, but queue:work never told me anything.

Not sure if this helps anyone, but do check your laravel.log just in case it's crapping out somewhere.

[huglester]

I do not see errors on queue:work either. that's why I use : queue:listen, for me it shows exceptions, etc. but is all this connected? isn't this another issue @TesseractG ? /cc @themsaid

[gboor]

@huglester I am not sure if it is the same issue at all, I am just saying that I ran into similar symptoms and this is how they were fixed. Perhaps it helps other people.

[bjufre]

Any idea why this is happening? I'm running into the same problem and database queueing...

[Donkfather]

I get this in the log :
local.ERROR: Predis\Response\ServerException: ERR unknown command 'EVAL' in C:\PROJECTS\blog\vendor\predis\predis\src\Client.php:370

windows 10 here :)

Solved: Old version of redis-server. Updated and now it works

[laurencei]

@zho - that is not a bug - you must put queue:work --queue:sendNotification

@behind-design @grepollo @brazenvoid @wtim @gmatkowski @waylaidwanderer
Are you still having the problem? Does it occur for you on 5.3?

I'm testing it on a Windows 10 box, and I've tried 5.1.* , 5.2.* and 5.3.* and it is working for me to process jobs on the database queue.

Can I confirm - are you using unique tubes? You need to run them explicitly like: queue:work --queue:sendNotification

[bjufre]

@lioannou I no longer have the problem with queue:work. But I must say that I went from database queuing to SQS.

But you're right, my co-worker had the same problem and doing queue:restart and specifying the queue like you said: queue:work --queue:sendNotification (for example), worked or so I'm told :)

[sachinsolanki]

I have same problem my jobs are inserted into job table but never execute by php artisan queue::work or php artisan queue::listen

[reno1979]

(Laravel 5.3)
Almost the same here, only on Homestead.

The listen method works, but using the work method causes the jobs not to be started anymore.

Update: Fixed, we had multiple queue:work daemons, all with their default name. by using the option --queue=uniqueName it all works again.

[themsaid]

Can someone confirm the issue still exists in laravel 5.4?

[laurencei]

@themsaid - for me - running Windows 10, on Homestead v1.0, using both database and redis drivers, it is working for me on Laravel 5.1 -> 5.4 (I've tried all versions).

If people are having issues - it might be somehow related to their environment? We'll need more info (I'm happy to do more testing if people can post their config)

[hafeez1042]

Having same issue,
Laravel version=5.4
QUEUE_DRIVER=beanstalkd
OS = MacOS

Also tried with redis

[mrliptontea]

You need to be specific about which queue(s) your worker is going to process.

The default queue is called default. If you run php artisan queue:work it will only process the default queue. Laravel does not magically know what queues you want to use. So, if for example, you dispatched a job on the emails queue, then make sure to pass --queue=emails,default to the worker/listener command.

Although I would agree that the documentation could be clearer on this topic.

[sachinsolanki]

I think you should be define queue name first then process to queue.

$job = (new ProcessPodcast($podcast))->onQueue('email');

Then check your code within constructor of job if every thing do well then you can add your queue code below in handle function.

Sometime if your code have any error then queue not working.

[laurencei]

@hafeez1042 - can you please paste your queue config, and also what command you are using to run the queue?

[wdda]

I did it!

Working example:
artisan queue:work database --queue=emails

Required parameter: database and --queue

[laurencei]

@themsaid - I feel this should/can be closed.

When you read many of the comments in this thread saying theirs is not working - many of them were incorrectly not applying the right queue name to be processed. I count at least 5 of them.

No one is able to provide any config that truly fails despite repeated requests. I've run lots of tests on Windows - and it works fine.

If it was a framework/Windows issue - we've had hundreds of people reporting it by now.

[ursuleacv]

Having the same problem:
Laravel 5.4.23
Windows 10 Home
Redis 2.8.17

There is no output for php artisan queue:work, or for queue:listen

When using QUEUE_DRIVER=database everything works fine

.env

BROADCAST_DRIVER=redis
CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=redis

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

in redis queues->default

{
  "displayName": "App\\Jobs\\MailMessage",
  "job": "Illuminate\\Queue\\CallQueuedHandler@call",
  "maxTries": null,
  "timeout": null,
  "data": {
    "commandName": "App\\Jobs\\MailMessage",
...

[mrliptontea]

@ursuleacv just to confirm, could you paste the exact command(s) which you run in redis-cli (or whatever you use to get that JSON you provided) to check what's in the queue?

Also, check if it works when you pass the queue name, and try to experiment with different queue names:
php artisan queue:work redis --queue=default

[ursuleacv]

@mrliptontea I am using Redis Desktop Manager. I tried with the queue name and it's the same, still not working.

[mrliptontea]

@ursuleacv only just now I have noticed Redis version which you use. Generally, Redis isn't officially supported on Windows, so where you got that actual build might be important.

I've just tried it on Redis 3.0.504 from MSOpenTech, and it all definitely works for me (Windows 10, Laravel 5.4.23).

[themsaid]

Reading all comments in this thread I find that it's most probably an environment misconfiguration since many people report that it's working or got it to work themselves. For that I'm closing this issue since I don't see a point in keeping it since no laravel core changes would be applied.

I suggest that people visiting this thread later to read all the comments and make sure they applied all the suggestions.

[mirko77]

@themsaid while I agree most of the time is a configuration issue, it should be made clear in the documentation on what environment the various artisan commands are tested.

I can confirm queue:work and queue:listen commands do not work on OS X High Sierra and no errors are shown.

The same commands work fine on an Ubuntu 16.04 VM.

[themsaid]

I can confirm queue:work and queue:listen commands do not work on OS X High Sierra and no errors are shown.

They work for me, that's the thing, really hard to find out what's wrong with your environment unless you dig yourself since you can replicate the issue.

[mrliptontea]

@mirko77 No errors on these commands will mean that queues you listen to are empty/don't exist, and that is expected. So far nothing proved there is an actual issue with the framework, it's always misconfiguration/misunderstanding.

Please, quadruple check:

• Queue driver you use.
• Queue name(s) you dispatch jobs on.

If you still don't find the cause:

• Trace what's being executed when you run queue:work (using a remote debugger or dd(); in the code).
• Whether you can manually see jobs in your queue driver.

[mirko77]

@mrliptontea the same exact code and commands run flawlessly on Ubuntu 16.04, just locally on a Mac High Sierra it does not.

While I could chase ghosts and witches for hours, I would just use sync when testing locally and live with that.

[mrliptontea]

But that's the point; it's not the code that's at fault but your environment, dependencies and their configuration, which is why I suggested checking your queue driver.

Maybe try Docker. If you're trying Redis then literally all you need is docker run -p 6379:6379 redis.

[pmochine]

So I don't know what happened. I needed to install laravel valet & node again. Now I'm back and tried to start my socket.io server with laravel-echo-server start and php artisan queue:work --tries=1 . But my console does nothing with queue. And it worked always for the last couple of months.

Nothing happens.

I did not change my .env at all and everything else works perfect on the page. I don't know how to fix this.

[mrliptontea]

@pmochine just like back in February, please check the following:

• Trace what's being executed when you run queue:work (using a remote debugger or dd(); in the code).
• Whether you can manually see jobs in your queue driver.

Honestly, I just tested this:

1. Install Laravel 5.2

   git clone https://github.com/laravel/laravel.git laravel52
   cd laravel52
   git checkout 5.2
   composer install
   composer require predis/predis
   cp .env.example .env
   php artisan key:generate
   

2. Create a test job

   php artisan make:job TestQueue
   

3. Edit app/Console/Commands/Inspire.php: add inside handle():

   dispatch(new \App\Jobs\TestQueue);
   

   Also, uncomment Commands\Inspire::class, in app/Console/Kernel.php.

4. Edit app/Jobs/TestQueue.php: add inside handle():

   \Log::info('Hello from the queue');
   

5. Run

   docker run --rm -p 6379:6379 -d redis
   php artisan inspire
   php artisan queue:work
   

6. Check the log

   tail storage/logs/laravel.log
   

   Should show something like

   [2018-07-04 20:20:20] local.INFO: Hello from the queue
   

[CoderFish8]

In my case php artisan queue:listen/work not worked while site in maintance mode
https://laravel.com/docs/5.6/configuration#maintenance-mode

[pmochine]

@CoderFish8 ... it was the same reason... stupid me

[Thirdwrist]

If you specified the connection or the queue when you add the job,you should run the listen or work command with connection and --queue,examples here:
php artisan queue:listen database --queue emails

This worked for me, Thanks!

[gigak7]

It helped me.Thanks!
I googled several hours. I used the command php artisan queue:listen --queue=your queue name(you can find it in your jobs table's queue columne) after I found this.

You need to be specific about which queue(s) your worker is going to process.

The default queue is called default. If you run php artisan queue:work it will only process the default queue. Laravel does not magically know what queues you want to use. So, if for example, you dispatched a job on the emails queue, then make sure to pass --queue=emails,default to the worker/listener command.

Although I would agree that the documentation could be clearer on this topic.

[Qh0stM4N]

@themsaid It's not a Bug, but there's something missing. --queue parameters like optional but the default value is heavily assigned to 'default'.
https://github.com/laravel/framework/blob/5042846eb0bdd0ade2e760015b1e5c57013225d5/src/Illuminate/Queue/DatabaseQueue.php#L50

When people give this optional parameter they intentionally only want certain queues to run. At the same time, it is developing in order of priority. doc: https://laravel.com/docs/5.4/queues#queue-priorities
expected: if a priorty is not specified, first in first out
happening: run only default queue. Not exist default; people googling

laravel queue not working

Neded wildcard support and defalut queue name = "*"
php artisan queue:work --queue=super,high,* 1. super 2. hing 3. other...
php artisan queue:work run All queue

[veniseactivation]

In my case php artisan queue:listen/work not worked while site in maintance mode
https://laravel.com/docs/5.6/configuration#maintenance-mode

Thank you @CoderFish8 that worked for me like magic after 5 hours of searching the problem was just in the maintenance mode

[M0nik]

I have the same problem. Wildcard support is really needed. Good solution @Qh0stM4N. The current behavior is not obvious. I use a lot of queues and why specify the name of each queue?

[helturkey]

In my case php artisan queue:listen/work not worked while site in maintance mode
https://laravel.com/docs/5.6/configuration#maintenance-mode

you saved my day, thanks, after more than 3 hours searching for.