Laravel queue worker using systemd.

laravel-queue.service

# Laravel queue worker using systemd
# ----------------------------------
#
# /lib/systemd/system/queue.service
#
# run this command to enable service:
# systemctl enable queue.service

[Unit]
Description=Laravel queue worker

[Service]
User=www-data
Group=www-data
Restart=on-failure
ExecStart=/usr/bin/php /path/to/laravel/artisan queue:work --daemon --env=production

[Install]
WantedBy=multi-user.target

I know this is a dead topic by now, but still gonna try to ask:
Anyone got to enable loging to a custom file? Like ./storage/logs/qworker/general.log ? How to add that to systemd? No matter what I try none works. :/

Got these here:
https://unix.stackexchange.com/questions/321709/redirect-systemd-service-logs-to-file
https://www.freedesktop.org/software/systemd/man/systemd.exec.html

One should add:
StandardOutput=append:/path/to/project/storage/log/queue.log
StandardError=append:/path/to/project/storage/log/queue.log

I am going to try it.

For those looking for some basic answers about how to use systemd, Justin Ellingwood wrote some great tutorials on the Digital Ocean blog, here's one for example: https://www.digitalocean.com/community/tutorials/systemd-essentials-working-with-services-units-and-the-journal

These are excellent resources, def worth familiarizing yourself with systemd's high-level concepts and basic commands, especially since things like NGINX and PHP-FPM are probably running on your servers using systemd.

I know the post was created awhile back does this still work? I do see service running and queue jobs are created but jobs don't get executed until I reexecute sudo systemctl start laravel_worker.service through ssh

Did you try what I've suggested? Use a nohup before PHP command. Also, what is the output for you journalctl -u laravel_worker.service ?

Thanks for the input.
Even I added /usr/bin/nohup on the ExecStart line the queue jobs are still not being processed. The following is the output for the command.

Thanks for the input. Even I added /usr/bin/nohup on the ExecStart line the queue jobs are still not being processed. The following is the output for the command.

Oh, now I see. You are executing the command in the wrong folder. See my example:

...
ExecStart=/usr/bin/nohup /usr/bin/php /var/www/html/laravel-project/artisan queue:work --daemon
...

Not simply php artisan queue:work. You need to add the folder too.

I now have this one set up still it doesn't start properly and require manual start up when ec2 restarts after new change is deployed

Here the log

If I explicitly call through ssh "sudo systemctl restart laravel_worker.service" then it will start executing jobs in queue too

If you execute the whole command, you have after you SSH-d in your server, what do you get?
So execute: /usr/bin/nohup /usr/bin/php /var/app/current/artisan queue:work --daemon

I get the following error.

/usr/bin/nohup: ignoring input and appending output to ‘/home/ec2-user/nohup.out’

but if I change to sudo php artisan queue:work --daemon
it works

https://stackoverflow.com/questions/24646320/nohupignoring-input-and-appending-output-to-nohup-out

It says just the message issue so it sounds like I don't need to change anything?

Check with this command if the queue worker runs or not: ps aux | grep artisan If there is more than 1 process, then you must kill all of them and start only one process again. If only 1 is present then you are good. If there is none, then the process is not running.

At the top of this post I mentioned the process is there just queue job doesn't get executed (which mens jobs are in the table) unless I manually type command "sudo php artisan queue:work" or "sudo systemctl start laravel_worker" My coworker said just put sudo systemctl start laravel_worker in postdeployment script. Then it seems to work. Is that how I supposed to do? Please advice.

If the process is there, but no actual job is being done, that looks like privileges issue. Make sure, the process is being run by the same user who is serving the application too. Also, I just noticed, running an artisan worker as root is very much not adviced.

oh I see thank you very much and I appreciate for being patient :)

the --daemon option is deprecated. programs under control of systemd should not daemonize anyway.

Having a bunch of issues with this ... freaking amazon removed supervisord from amazon linux 2023 and system d is the only way it seems but I'm not experience enough on how to use it. I just wish they would bring back supervisord