So I just faced this issue second time. First time I stopped that instance and created a new one as I coudn't resove it but happend the same in the second instance.
I was working on the Laravel queue and had to make the jobs run automatically so as per their document below I followed the steps.
https://laravel.com/docs/8.x/queues#supervisor-configuration
As soon as I run the "sudo supervisorctl update" command the whole instance stops working. SSH is also stop working so not sure how to resolve this issue.
The installation of supervisor and adding the laravel-worker.conf file works fine. Also the "sudo supervisorctl reread" works fine but as soon I run the update command, the whole instance stops working.
Please help.
updaing the Laravel-worker
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/mydomain.com/artisan queue:work
autostart=true
autorestart=true
user=ubuntu
numprocs=8
redirect_stderr=true
stdout_logfile=/var/www/mydomain.com/worker.log​
Related
I don't know what exactly happened but when ever I start:
php artisan queue:work & redis-server.exe (windows)
I get a lot of processings for 1 event even tho app is not used (opened on browser)
I am not even using this Event from picture....
I am so unsure why is this happening?
Well using redis-cli flushall and queue:work --tries=1 helped me clean all proceses that were stored within redis and fail after one try.
In Laravel 5.3.
I'm running through jenkin a command of laravel:
php artisan queue:work
But I need to stop it. Ideally I would like to stop the worker after the queue jobs gets empty, but it's not possible on Laravel 5.3. So another option would be to stop the command after sometime, let's say 1 minute.
How can I stop a process running through jenkins after some time? or stop a php artisan command.
With php artisan queue:restart I can stop all the jobs so I tried:
php artisan queue:work
sleep 60; php artisan queue:restart
But that 2nd line will never get reached because the workers is still running.
Any tip?
you can use some solution form solve it
1.
You save server resources by avoiding booting up the whole app on
every job.
You have to manually restart the worker to reflect any
code change you made in your application.
You can also run:
php artisan queue:work --once
2- This will start an instance of the application, process a single job, and then kill the script.
php artisan queue:listen
The queue:listen command simply runs the queue:work --once command inside an infinite loop, this will cause the following:
An instance of the app is booted up on every loop.
The assigned worker will pick a single job and execute it.
The worker process will be killed.
Using queue:listen ensures that a new instance of the app is created for every job, that means you don't have to manually restart the worker in case you made changes to your code, but also means more server resources will be consumed.
I followed the official Laravel doc to start queue in the background using supervisor in Centos 7.
But whene I run this command sudo supervisorctl start laravel-worker:* I get this error laravel-worker: ERROR (no such group)
Documentation:
https://laravel.com/docs/5.5/queues#supervisor-configuration
I tested it out and created a new server with no supervisor configurations at all. These were my steps to get it running:
# 1. create the config file, see below for content
vi /etc/supervisor/conf.d/laravel-worker.conf
# 2. Reload the daemon's configuration files
supervisorctl reread
> laravel-worker: available
# 3. Reload config and add/remove as necessary
supervisorctl update
> laravel-worker: added process group
# 4. Start all processes of the group "laravel-worker"
supervisorctl start laravel-worker:*
# 5. Get status for all processes of the group "laravel-worker"
supervisorctl status laravel-worker:*
> laravel-worker:laravel-worker_00 RUNNING pid 23758, uptime 0:00:16
> laravel-worker:laravel-worker_01 RUNNING pid 23759, uptime 0:00:16
# 6. After a change in php sources you have to restart the queue, since queue:work does run as daemon
php artisan queue:restart
> Broadcasting queue restart signal.
/etc/supervisor/conf.d/laravel-worker.conf
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/artisan queue:work --sleep=3 --tries=2
autostart=true
autorestart=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/storage/logs/supervisor_queue-work.log
I've the same problem on my cloud based vps. Please check the bottom of supervisord.conf file.
You can find it on
nano /etc/supervisord.conf
You should carry the [includes] section on the configuration file. If the section looks like above.
[include]
files = supervisord.d/*.ini
change the files parameter extension to .conf instead
[include]
files = supervisord.d/*.conf
otherwise supervisor can not find the laravel-worker configuration.
Put quotes around worker name sudo supervisorctl start 'laravel-worker:*'
Be sure that the top of your config file is correct. Example:
[program:laravel-worker]
The below will cause your problem:
[program: laravel-worker]
[laravel-worker]
Cheers
See the process name on config file.
my file was like this
[program:omni-delivery-dev-server.config]
...
and it stayed like this
[program:omni-delivery-dev-server]
...
If you have centos8 locate and check supervisor.conf . At the very last you may find
[include]
files = supervisord.d/*.ini
So don't worry rename your-file.conf to your-file.ini
and try these commands again
supervisorctl reread
If you see the change then this is success.
supervisorctl update
supervisorctl start laravel-worker:*
note: if you get some supervisorctl start laravel-worker:* message
try adding quote in
supervisorctl start 'laravel-worker:*'
in new version of supervisor configuration file format is *.ini not *.conf so rename your file laravel-worker.conf to laravel-worker.ini and run other commands
supervisorctl reread
supervisorctl update
supervisorctl start laravel-worker:*
I have installed & configured supervisor.
ps -ax shows 10 processes such as:
php /home/vagrant/Sites/mysite/artisan queue:work --tries=1
However when I put something in queue it stays there and nothing happens. But if I run this command manually (even under vagrant user, exactly how it does supervisor) everything works.
I use Redis for keeping queues.
What can be the reason?
update
So, here is some additional info, since I really couldn't figure it out.
Laravel 5.5 version
Actually I have two supervisor configs for 2 projects. First one seemed to be working. Second doesn't. I mean, I can see the processes by ps -ax, but nothing happens. Both configs are identical:
[program:mysite-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /home/vagrant/Sites/mysite/artisan queue:work --tries=1
autostart=true
autorestart=true
user=vagrant
numprocs=10
redirect_stderr=true
stdout_logfile=/home/vagrant/Sites/mysite/worker.log
Also I couldn't figure out how can I enable and disabled some configs (like en2site for supervisord :) )
So, when I put something in the queue I can see it in redis. Then I manually run php /home/vagrant/Sites/mysite/artisan queue:work --tries=1 under vagrant user and queue jobs are dispatched and run. But only if I run the command manually =\
I was about the same problem.
The issue is apears becouse supervisor when call
php /home/vagrant/Sites/mysite/artisan queue:work --tries=1
actualy not in project working directory, and artisan cant find .env file.
so you have some option to handle this:
set your enviroment variables from .env file
or
add directory parametr to your supervisor config
directory="path/to/your/project"
or
set set_include_path in php.ini to your project folder
Here's an odd one. I'm running supervisor 3.13 with beanstalkd for a Laravel 4.1 queue. I have a /stage/ and /production/ instances of my app running. I'm running supervisor programs to run artisan queue:listen (out of separate .conf files) for each as follows:
[program:appname-production]
command=php artisan queue:listen --env=production
directory=/home/servername/public_html/production
stdout_logfile=/home/servername/public_html/production/app/storage/logs/supervisord.log
redirect_stderr=true
autostart=true
autorestart=true
The only difference is replacing production with stage in the program. However, when supervisor runs, only the stage program executes correctly. The production program shows FATAL Exited too quickly
appname-production FATAL Exited too quickly (process log may have details)
appname-stage RUNNING pid 6784, uptime 0:32:01
The stage queue is working fine as shown in ps aux. Also, running artisan queue:listen in the production folder works just as it should. When I examine the supervisord log for production however, it's full of:
X-Powered-By: PHP/5.5.20
Content-type: text/html
[InvalidArgumentException]
There are no commands defined in the "queue" namespace.
I've exhausted my technical knowledge of the setup here - I can't seem to reason out why two cloned setups are behaving differently. I've only been able to guess that supervisor is getting boggled somewhere - as I can get the production queue working fine by doing it manually.
All help / ideas are very appreciated.
Finally fixed this and wanted to share. Like other solutions, the fix had to do with setting an absolute path to php. However, the PATH var also needed to be set via environment in the subprocess conf. Here we go:
[program:appname]
command=/usr/local/bin/php artisan queue:listen --env=production
directory=/home/appdir
stdout_logfile=/home/appdir/app/storage/logs/supervisord.log
redirect_stderr=true
autostart=true
autorestart=true
environment=PATH="/usr/local/bin"
Hope this helps someone in the future!