Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.3] ProcessTimedOutException when calling queue:listen #14792

Closed
ryantbrown opened this issue Aug 12, 2016 · 12 comments
Closed

[5.3] ProcessTimedOutException when calling queue:listen #14792

ryantbrown opened this issue Aug 12, 2016 · 12 comments

Comments

@ryantbrown
Copy link

When I run php artisan queue:listen sqs I get the following error:

[Symfony\Component\Process\Exception\ProcessTimedOutException]
The process "'/usr/bin/php7.0' 'artisan' queue:work 'sqs' --queue='grin-market-1' --delay=0 --memory=128 --sleep=3 --tries=0 --env='local'" exceeded the timeout of 60 seconds.

The timeout occurs when the process reaches the --timeout value, whether any jobs are being fired or not. Jobs that fire before the timeout are working properly, but the process dies when the --timeout is reached.

I did not see any other issues related to this specifically. Also, its entirely possible I am doing something wrong, but I have used queues many times with Laravel 5.2 and below without incident.

@GrahamCampbell
Copy link
Member

Does this only happen on sqs please?

@ryantbrown
Copy link
Author

This is happening with beanstalkd, redis and sync drivers as well. Jobs fire correctly with all 4 drivers when they are processed before the timeout.

screen shot 2016-08-12 at 11 02 42 am

@GrahamCampbell
Copy link
Member

Odd, I can't replicate this. What version of PHP are you using please?

@GrahamCampbell
Copy link
Member

Wait, isn't this correct. You're meant to call work, not listen.

@ryantbrown
Copy link
Author

Homestead with PHP PHP 7.0.8-2+deb.sury.org~xenial+1.

The listen command calls work underneath. Running work results in the same issue

@GrahamCampbell
Copy link
Member

Oh, I see why this is happing. We were meant to pass through --once to the work command to make it process exactly one job.

@ryantbrown
Copy link
Author

Ok so if I call work with --once on my end this will be resolved for now?

@GrahamCampbell
Copy link
Member

No. It's an internal command we're calling.

@ryantbrown
Copy link
Author

Never mind I see the problem. I can fix it for now and then update later

@GrahamCampbell
Copy link
Member

Fixed in d0bc401. :)

@ryantbrown
Copy link
Author

Word thanks

@GrahamCampbell
Copy link
Member

Thanks for reporting! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants