Sending email on remote forge / envoyer

PHP caches the folder path but that may not be the problem you're having. Do you use /releases/latest/ as a symlink or is it the timestamp?

Thanks for the reply Bashy. The path is set to /current/public in Forge and then I think Enyoyer sets a symlink to map the current directory to the latest timestamped named release folder. I'm not sure exactly how it works, as I'm not really big on servers, which is why I use Forge & Envoyer. I've been using Forge and Envoyer for a while now (probably about a year) and this error has only occurred in last 3 days without me doing anything on the server apart from pushing new releases.

Any suggestions about what I can try and do to resolve this situation.

Thanks, Rob

Sounds very much like PHP path cache. Have a look here and see if this matches up: http://stackoverflow.com/questions/18450076/capistrano-symlinks-being-cached

Depends how long this has been happening as it's not a massive cache time by default.

Thanks. I'll take a look.

Just been reading the docs for queues and I've come across this:

Since daemon queue workers are long-lived processes, they will not pick up changes in your code without being restarted. So, the simplest way to deploy an application using daemon queue workers is to restart the workers during your deployment script. You may gracefully restart all of the workers by including the following command in your deployment script:

php artisan queue:restart This command will gracefully instruct all queue workers to restart after they finish processing their current job so that no existing jobs are lost.

So I'll have a fiddle now and see if I can get it to work and post back here with what works.

Thanks once again for your time, Rob

Oh true, forgot about that :)

I edited the deployment hooks to restart the queues after the 'activate new release' hook using the following

cd {{release}}

php artisan queue:restart

but that didn't work.

When I went to forge and restarted the queue manually, it worked and solved the problem.

Aside from manually going in and restarting the queue in forge, does anybody know how I can stop this happening in the future ?

Thanks, Rob