$ php artisan queue:listen



$ nohup php artisan queue:listen &



Nothing really has a state - instances can go down and up independently of the application

This is especially true when AutoScaling is configured

Deploying can crash the queue-listener

The server could reboot for various reasons

Your queue-listener could crash for various reasons (this happens the most)

Application error (PHP exception, for example while working off a malformed payload)



SQS is down (yup, it happens!)

Install Supervisor Make sure it runs after a reboot stop the queue-worker shortly before a new application version goes live start the queue-worker shortly after a new application version went live

$ supervisorctl tail -1000 laravel_queue

$ supervisorctl tail -1000 laravel_queue stderr

$ supervisorctl status

$ supervisorctl start laravel_queue

$ supervisorctl stop laravel_queue

Job and/or message queues is an important component of a modern web application. Simple calls like sending verification emails should always be pushed to a queue instead of done directly, as these calls are expensive and will cause the user to wait a while for the website to finish loading.In this blog post I will write how to keep a stablerunning on anenvironment with the help of the watchdog: Supervisor First checkout queues.io for a list of queue-daemons and of course Laravel's 5 own documentation page about queues so you know what's coming up.You will then most probably come to the conclusion that you need to run the following command for your queue to be actually processed:Now, I have already seen the weirdest setups, but the most prominent might be maybe something like this:Theat the end will cause the call to go into the background, and the precedingwill make sure that it will keep running even if you exit your shell.Personally I would always do something like this in afor various reasons - especially for convenience.Anyways, on your server you will want this to run stable, for as long as possible, and automatically restart on crashes or server reboots.This is especially true on ElasticBeanstalk, Amazon's poorly but unfortunately popular implementation of a "Platform as a Service":To get a grip of this you definitely need to use some kind of watchdog. You can either go with monit or use Supervisor which I found was easier to configure.Use the following .ebextension to achieve the following:You will notice that you have to set a new param SUPERVISE and set it to "enable" for the script to run. This allows me to switch it on - depending on the environment - or off, if a script is causing problems.Also be aware, this will only work with newer ElasticBeanstalk versions (1.3+).I almost forgot to mention the following commands (do not run as root!) that will help you around.