Skip to content

Instantly share code, notes, and snippets.

@thomasjsn
Last active April 26, 2024 09:34
Show Gist options
  • Save thomasjsn/bc7d3a3b81d0118f6e89eef7d43f66f3 to your computer and use it in GitHub Desktop.
Save thomasjsn/bc7d3a3b81d0118f6e89eef7d43f66f3 to your computer and use it in GitHub Desktop.
Laravel queue worker using systemd.
# 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
@cmsouza
Copy link

cmsouza commented Aug 15, 2017

Also, the correct location of the file is on /etc/systemd/system/ not on /lib/systemd/system.

Those are the directories (https://wiki.archlinux.org/index.php/Systemd/User)

/usr/lib/systemd/user/ where units provided by installed packages belong.
~/.local/share/systemd/user/ where units of packages that have been installed in the home directory belong.
/etc/systemd/user/ where system-wide user units are placed by the system administrator.
~/.config/systemd/user/ where the user puts its own units.

@Adesubomi
Copy link

Please, how do I start the process after creating the file? And what is the Linux command to list all the running services, to know that it's running?

@thehypergraph
Copy link

thehypergraph commented Apr 30, 2018

Thanks for posting this. I just used it on a Centos 7 cPanel server.

The only catch I had was that I had to replace the www-data with the user and group the files were registered under as cPanel executes PHP under the system user name and not www-data.

Apart from that all I had to do to get it going was run:

systemctl enable laravel-queue.service

systemctl start laravel-queue.service

Also, when I made a change the service file I had to run:

systemctl daemon-reload

systemctl restart laravel-queue.service to restart it.

All in all, it was very easy, thanks!

@bertalanimre
Copy link

bertalanimre commented Sep 18, 2018

For me it is not working. I constantly get the following:

[myuser@webserver laravel-project]$ systemctl status queuework
● queuework.service - Laravel queue worker
   Loaded: loaded (/etc/systemd/system/queuework.service; disabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Tue 2018-09-18 10:18:45 CEST; 4s ago
  Process: 25837 ExecStart=/usr/bin/php /var/www/html/laravel-project/artisan queue:work --daemon (code=exited, status=217/USER)
 Main PID: 25837 (code=exited, status=217/USER)

Sep 18 10:18:44 webserver systemd[1]: Unit queuework.service entered failed state.
Sep 18 10:18:44 webserver systemd[1]: queuework.service failed.
Sep 18 10:18:45 webserver systemd[1]: queuework.service holdoff time over, scheduling restart.
Sep 18 10:18:45 webserver systemd[1]: start request repeated too quickly for queuework.service
Sep 18 10:18:45 webserver systemd[1]: Failed to start Laravel queue worker.
Sep 18 10:18:45 webserver systemd[1]: Unit queuework.service entered failed state.
Sep 18 10:18:45 webserver systemd[1]: queuework.service failed.

The command works fine if I execute it from the terminal. So I've fixed it by:
as rask suggested, set the Restart option to always
and for start I've used a nohup command before php

This way it is working like a charm and also restarts if I kill the process manually. systemctl restart and stop also works.

# 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=nginx
Group=nginx
Restart=always
ExecStart=/usr/bin/nohup /usr/bin/php /var/www/html/laravel-project/artisan queue:work --daemon

[Install]
WantedBy=multi-user.target

@bertalanimre
Copy link

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. :/

@svamja
Copy link

svamja commented Feb 3, 2020

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.

@timrourke
Copy link

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.

@tentree-development
Copy link

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
image

image

@bertalanimre
Copy link

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 ?

@tentree-development
Copy link

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.

image

@bertalanimre
Copy link

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.

image

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.

@tentree-development
Copy link

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
image

@tentree-development
Copy link

Here the log
image

@tentree-development
Copy link

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

@bertalanimre
Copy link

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

@tentree-development
Copy link

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

@tentree-development
Copy link

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

@bertalanimre
Copy link

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.

@tentree-development
Copy link

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.

@bertalanimre
Copy link

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.

@tentree-development
Copy link

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

@glaszig
Copy link

glaszig commented May 18, 2023

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

@cAstraea
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment