-
-
Save thomasjsn/bc7d3a3b81d0118f6e89eef7d43f66f3 to your computer and use it in GitHub Desktop.
# 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 |
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
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
Here the log