I think I have solved this.

I added

php artisan down

followed by:

php artisan up

on my worker box in the Envoyer deployment hooks, and it seems to work now.

How do you have the queue workers started in the first place? Do you have anything monitoring them in case they fail? (supervisord/upstart?)

Those usually provide a way to restart/reload them. Check out these videos on process monitoring to see some examples for supervisord or upstart. (Upstart comes with Ubuntu servers, so if you want to avoid installing another thing, try that first).

chood531, where did you add php artisan down and php artisan up commands in relation to php artisan queue:restart?

I've been running into a lot of issues using Beanstalkd with Forge (Digital Ocean) and Envoyer.

I have two queue workers, neither running as daemon. It seems that, randomly, they stop working entirely - possibly after a deployment. I just restarted them and all of the sudden a flood of held queue jobs broke loose.

Aren't queue workers supposed to restart themselves if they die? Do I need to do something special with Envoyer (like a hook of some sort) to make sure that my queues are still working? I do not want to be forced into using Iron but I cannot seem to make these queues reliable.

I am having the same problem.

php artisan down php artisan up

Doesn't work, or does php artisan queue:restart.

Restarting the queue process within Forge does. I haven't set this up as a daemon.

What is Taylor doing in that Forge reset process?

After a quick envoyer support request to Taylor I (he) solved this as follows:

Setup the queue processor in Forge as a Daemon.

Then the queue:restart process will work properly.

Now I need to monitor my queue processing tools to ensure they are not leaking memory!

I'm trying to get a Capistrano deploy script to work with 1 queue worker running (which I started via Forge), but I get the same issue: the queue worker keeps running jobs in the old release directory.

After publishing the "current" symlink with Capistrano, I do this:

sudo service php5-fpm reload
php artisan queue:restart
// clear cache etc.

Adding php artisan up and down doesn't help. Making the queue worker run as a deamon seems to help sometimes, but not every deploy... I also tried to add a sleep 5 before the restart, but no luck.

Using the restart button on Forge works... And running php artisan queue:restart manually also seems to work every time (when it is a deamon).

Any other ideas?

Edit:

When running the worker as a daemon, it seems to be functioning properly when I clear the cache BEFORE restarting the queue worker.

sudo service php5-fpm reload
// clear cache etc.
php artisan queue:restart

It keeps failing when it's not a daemon, so I guess I'll stick with the daemon for now... Should I be worried about memory leakage?? @harikant

If you're running non-daemon queue listeners, then "queue:restart" seems to be irrelevant. But killing the "queue:listen" process seems to do the trick! I was playing around with this and tried to automate this for my deploy script...

I created a console command (queue:stop) to run in the "current" project root after deploying a new release. The script then finds queue:listen processes fired from this directory (and as user "forge") and then kills it.

I tried this and it appears to work every time!

Can anyone review this? Is this usable?

https://gist.github.com/ivanvermeyen/4a4ba5146d61d19c61dc

I've recently switched to running my queue processor as a daemon on Forge. I was using the PHP process originally, but with the 10 second wait time it was filling my app monitoring tool with processes just over 10 seconds long.

My deployment process on the worker server goes

• install composer dependencies
• artisan down
• migrate
• activate new release
• artisan up
• php artisan queue:restart

Which seems to be fine. And after I have a php /home/forge/app.domain/current/artisan queue:work database --sleep=3 --da process.

For peace of mind I'd like to add a little script that resolves /home/forge/app.domain/currentand pings me an email or slack notification... just to be sure though :) Any ideas on how best to add this?

I would love to get more information on this, especially for those of us not using Forge and only using Envoyer.

Is it possible using only Envoyer? setting up the queue workers?

For what it's worth for those of you having issues with queue restarts and email view caching on a forge/envoyer setup I had to place the php artisan queue:restart in the "after activate new release" hook and php artisan view:clear and php artisan cache:clear in the before activate hook. I also switched my workers to daemons in forge settings. My view templates seem to refresh properly after all that.

I know this is an old topic but it's the first on google so I'll post it in here (so at least I can find it when I need it again b/c I've been through this before)

So I've had queue issues for a few years now, suddenly it just stops working after a deploy. The normal php artisan queue:restart etc described above didn't always seem to fix it all of the time. I just couldn't put my finger on why, doing it manually works fine.

So finally after much headache, I found the only way I can ensure that the queue restarts properly 100% of the time is if I do sudo supervisorctl restart all.

Now to get that working as part of the envoyer deploy process I had to add a hook after "Activate new release"

The hook looks like:

sudo /home/forge/restart-queue

The file I am using looks like this: /home/forge/restart-queue

#!/bin/bash

sudo supervisorctl restart all

After you save that you need to do your usual chmod +x /home/forge/restart-queue

Now to get it running inside envoyer (because sudo doesn't work) modify the sudoers file (sudo visudo) and add the following to the file forge ALL=NOPASSWD: /home/forge/restart-queue (might have added this somewhere else too for forge's sake)

Now everything works all of the time. I even throw in a queue restart once a week as a cron job.

The following hook is tested in use

cd {{project}}/current
php artisan queue:restart

Use Laravel Horizon to manage queues and then add a deployment hook with the following commands:

cd {{ release }}

Publish horizon assets

php artisan horizon:publish

Gracefully terminate old horizon daemon

php artisan horizon:terminate

At forge run a daemon for the command php artisan horizon