php artisan queue:restart?

In Envoyer you can do the following....

cd \{{release\}}
php artisan queue:restart

This will put you in the current release directory. While this will work for restarting the queue, I am not sure if it will maintain the daemon on Forge. I am unaware of any Forge hooks from Envoyer. Might be something @TaylorOtwell will add one day.

However, based on our past convos about queues on various threads you might be fine setting up a queue:worker command with the --daemon flag on your server. Then using the restart should gracefully restart it while maintaining the daemon (if I understand the docs right).

NOTE It is apparent you probably tried to type the release command in your code but for some reason the code snippet was pulling it out. I had to put slashes in there to get them to show up.

@BENderIsGr8te Just read the docs again:

Deploying With Daemon Queue Listeners

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

So I guess the webhook would be as I mentioned before - CD into the current release and run the command. But another part that I do not understand:

Note: This command relies on the cache system to schedule the restart. By default, APCu does not work for CLI jobs. If you are using APCu, add apc.enable_cli=1 to your APCu configuration.

Do I need to worry about this with a Forge/DO server?

@opheliadesign

The queue stores a timestamp in whatever Laravel is configured to use for it's cache. The queue:restart command updates that timestamp, which signals the queue worker to stop (quit). It then gets restarted because supervisord or some other process monitor is ensuring it restarts if it quits. This is a graceful restart, as it waits until a job is complete before quitting.

The important part here is that it uses Laravel's cache library to store that data.

The default cache driver is file. Popularly also used is memchaced or redis. You can see what you have configured by checking your .env file or the cache.php config file.

The key point there is - that's based on your configuration. APC is an option for caching, so if you're using that, there may be an issue. You're likely not using that, otherwise you'd probably know it! Servers created by forge have Memcached and Redis installed (not APC), but keep in mind that what is used depends on your application configuration.

@fideloper thanks for getting back to me. Cache driver is indeed set to file, should I change that to memcached or redis?

hmmm, perhaps. I think you might get other errors if the cache wasn't writable (in other words, that cache driver might not be the issue).

Worth a shot tho.

Sorry for getting back to you so long after.

Hi,

I just stumbled upon this thread because I was facing the same issue. Maybe I found a way to resolve this, but it would be nice if someone could review it. I don't know if this is the best way to go about this, but so far it's the only way that I found to be working for me.

I also posted this in another thread, but didn't get a response yet:

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!

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

Hi @fideloper , @ivanv , Does the queue:restart reconsider the changes in the ENV files? At the moment I'm facing an issue were the new added variables in the ENV file are not considered even after restarting the queue.

Any thoughts regarding?

Thanks.

@alexmansour Not sure 'bout that... Maybe you need to run php artisan config:clear first?

@ivanv Thanks for your reply. I actually I'm already running the config:clear before running queue:restart. I ended up fixing the issue by giving default value for the added ENV variable but it would be great if we can get a result regarding.

I saw someone suggesting that it might be because of the cache driver, which led me to the solution to the same problem OP encountered. I switched to redis and my queues restarted after a short while. In other threads I've also read that this is the probable culprit.

@ivanv,

Estava com um problema na minha aplicação visto que após realizar alterações no ambiente local e deploy em minha vps vultr, essas mesmas alterações não estavam surtindo efeito em ambiente de produção porque o laravel continuava a identificar a versão anterior dos arquivos alterados. Utilizei o comando

php artisan config:clear 

sugerido por você e resolveu meu problema. Esta é uma nota apenas para fornecer feedback e agradecimento pelo seu post.

@michelpureza thanks for the feedback :)

If it might be of any help to anyone... I've put my current deploy script on GitHub: https://github.com/codezero-be/laravel-cap-deploy

I'm running daemon queues on Forge and the deploy steps look like this:

• fetch the latest changes from git repo
• create a release folder
• run composer install
• run php artisan optimize
• migrate the database
• update the current symlink to the new release folder
• reload PHP-FPM
• clear the cache
• recache the routes and config
• restart the queue daemon

just a quick update.. all this discussion about deamon vs non-deamon is irrelevant by now.. since the whole deamon option has been deprecated for a while (i ran this on my old laravel 5.3 app):

php artisan queue:work --help
Usage:
  queue:work [options] [--] [<connection>]

Arguments:
  connection               The name of connection

Options:
      --queue[=QUEUE]      The queue to listen on
      --daemon             Run the worker in daemon mode (Deprecated)
      --once               Only process the next job on the queue
      --delay[=DELAY]      Amount of time to delay failed jobs [default: "0"]
      --force              Force the worker to run even in maintenance mode
      --memory[=MEMORY]    The memory limit in megabytes [default: "128"]
      --sleep[=SLEEP]      Number of seconds to sleep when no job is available [default: "3"]
      --timeout[=TIMEOUT]  The number of seconds a child process can run [default: "60"]
      --tries[=TRIES]      Number of times to attempt a job before logging it failed [default: "0"]
  -h, --help               Display this help message
  -q, --quiet              Do not output any message
  -V, --version            Display this application version
      --ansi               Force ANSI output
      --no-ansi            Disable ANSI output
  -n, --no-interaction     Do not ask any interactive question
      --env[=ENV]          The environment the command should run under
  -v|vv|vvv, --verbose     Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  Start processing jobs on the queue as a daemon