How to keep Laravel Queue system running on server How to keep Laravel Queue system running on server laravel laravel

How to keep Laravel Queue system running on server


Running

nohup php artisan queue:work --daemon &

Will prevent the command exiting when you log out.

The trailing ampersand (&) causes process start in the background, so you can continue to use the shell and do not have to wait until the script is finished.

See nohup

nohup - run a command immune to hangups, with output to a non-tty

This will output information to a file entitled nohup.out in the directory where you run the command. If you have no interest in the output you can redirect stdout and stderr to /dev/null, or similarly you could output it into your normal laravel log. For example

nohup php artisan queue:work --daemon > /dev/null 2>&1 &nohup php artisan queue:work --daemon > app/storage/logs/laravel.log &

But you should also use something like Supervisord to ensure that the service remains running and is restarted after crashes/failures.


You should use linux supervisor

Installation is simple and on Ubuntu I can install it with following command:

apt-get install supervisor

Supervisor configuration files are located in /etc/supervisor/conf.d directory.

[program:email-queue]process_name=%(program_name)s_%(process_num)02dcommand=php /var/www/laravel-example/artisan queue:work redis --queue=emailqueue --sleep=3 --tries=3autostart=trueautorestart=trueuser=forgenumprocs=2redirect_stderr=truestdout_logfile=/var/www/laravel-example//storage/logs/supervisord.log

For each process you should create a new process configuration file. With this configuration, listener will retry each job 3 times. Also Supervisor will restart listener if it fails or if system restarts.


The command

nohup php artisan queue:work --daemon &

was correct, it would allow the process to continue after closing the SSH connection; however, this is only a short term fix. Once your server is rebooted or any issue causes the process to stop you will need to go back and run the command again. When that occurs, you never know. It could happen on a Friday night, so it is better to implement a long term solution.

I ended up switching over to Supervisord, this can be installed on Ubuntu as easy as

sudo apt-get install supervisor 

For AWS-AMI or RedHat users you can follow the set of instructions I outlined in this question:

Setting up Supervisord on a AWS AMI Linux Server