I'm facing an issue with supervisor & kubernetes.
Below is my supervisor config for laravel queue worker.
[program:queue-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan queue:work --sleep=10 --tries=3 --max-time=3600 --timeout=90 --daemon
user=nobody
autostart=true
autorestart=false
stopasgroup=true
killasgroup=true
numprocs=1
redirect_stderr=true
stdout_logfile=/var/www/html/queue-worker.log
stopwaitsecs=50
stopsignal=TERM
when my container is terminating, a supervisor is still running in the background. It is not listing to the SIGTERM from Kubernetes.
if I try to stop using the preStop hook from Kubernetes and run the command /usr/bin/supervisorctl stop queue-worker:* then it stops immediately without waiting for 50 sec as mentioned in config.
To resolve the issue, I'm started Nginx and PHP-fpm with the worker using a supervisor. So basically supervisor has PID 1 and it will receive SIGTERM before the pod stops from Kubernetes.
Note: Kubernetes send SIGTERM signal only to Process with ID 1. No child process receives a SIGTERM signal. If you want to send SIGTERM or any other POSIX signal to the process, then you can use the preStop hook.
Related
I'm using supervisor with laravel on ubuntu
there are many jobs in jobs table but they are not processing
/etc/supervisor/conf.d/queue-worker.conf
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/site/artisan queue:work sqs --sleep=3 --tries=3 -->
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=root
numprocs=8
redirect_stderr=true
stdout_logfile=/var/www/site/storage/logs/worker.log
stopwaitsecs=3600
sudo supervisorctl status queue-worker:*
queue-worker:queue-worker_00 RUNNING pid 1527816, uptime 0:36:16
queue-worker:queue-worker_01 RUNNING pid 1527820, uptime 0:36:16
queue-worker:queue-worker_02 RUNNING pid 1527804, uptime 0:36:17
queue-worker:queue-worker_03 RUNNING pid 1527802, uptime 0:36:17
queue-worker:queue-worker_04 RUNNING pid 1527815, uptime 0:36:16
queue-worker:queue-worker_05 RUNNING pid 1527793, uptime 0:36:17
queue-worker:queue-worker_06 RUNNING pid 1527835, uptime 0:36:16
queue-worker:queue-worker_07 RUNNING pid 1527807, uptime 0:36:17
also i run this command
sudo php artisan queue:restart
but it doesn't work
You said you are using database on a comment, how do you expect to process jobs if you are running php artisan queue:work sqs, you are literally executing the SQS queue, not database...
So use this command=php /var/www/site/artisan queue:work database --sleep=3 --tries=3 (or just run without writting database, but QUEUE_CONNECTION env must be database)
I am trying to dispatch a job by laravel queue:work using supervisor in the live server (CentOS 7). Supervisor is running but the job is not processing. I am getting following error:
My worker file is :
[program:queue-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /home/maomin/public_html/bvend.xyz/artisan queue:work sqs --sleep=3 --tries=3 --max-time=3600 --daemon
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=apache
numprocs=8
redirect_stderr=true
stdout_logfile=/home/maomin/public_html/bvend.xyz/w.log
stopwaitsecs=3600
log file (/home/maomin/public_html/bvend.xyz/w.log) shows below error :
The "--max-time" option does not exist.
I have tried almost all google solution but no luck
solved the issue by doing following:
removed --max-time=3600 and replaced 'sqs' with 'database' as I am using database for queue job.
command=php /home/maomin/public_html/bvend.xyz/artisan queue:work sqs --sleep=3 --tries=3 --max-time=3600 --daemon
to
command=php /home/maomin/public_html/bvend.xyz/artisan queue:work database --sleep=3 --tries=3 --daemon
I am deploying a Laravel 7.28.3 app with Laradock on production mode.
So far the application is working in its domain.com with Let's Encrypt.
Since I am using the Email Verification feature, I want the php artisan queue:workrunning in the background. According to the docs, you can use the php-worker container.
So I set up all according to them, but the php-worker is not dispatching the queued jobs.
In the .env the queue connection driver is database:
QUEUE_CONNECTION=database
The configuration files are as follows:
laravel-worker.conf inside the php-worker/supervisord.d/ directory:
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/artisan queue:work --sleep=3 --tries=3 --daemon
autostart=true
autorestart=true
numprocs=8
user=root
redirect_stderr=true
In this case, I'm only running the nginx, mysql and php-worker containers. The docs say the workspace container is run automatically. So:
$ sudo docker-compose -f docker-compose.production.yml up --build nginx mysql php-worker
When scanning the realtime logs I get the following messages:
php-worker_1 | 2020-08-11 03:13:48,889 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
php-worker_1 | 2020-08-11 03:13:48,889 INFO Included extra file "/etc/supervisord.d/laravel-worker.conf" during parsing
php-worker_1 | 2020-08-11 03:13:48,895 INFO RPC interface 'supervisor' initialized
php-worker_1 | 2020-08-11 03:13:48,895 CRIT Server 'inet_http_server' running without any HTTP authentication checking
php-worker_1 | 2020-08-11 03:13:48,895 INFO supervisord started with pid 1
...
php-worker_1 | 2020-08-11 03:13:49,938 INFO spawned: 'laravel-worker_07' with pid 14
php-worker_1 | 2020-08-11 03:13:50,939 INFO success: laravel-worker_00 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
php-worker_1 | 2020-08-11 03:13:50,939 INFO success: laravel-worker_01 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Then I test the application by creating a new account (at /register), there's nothing reported at the logs by the php-worker.
Hmmm... now it's working!
Reference.
This works for me:
inside .env file add:
REDIS_CLIENT=predis
and then restart the Queue: php artisan queue:restart
I have two sites on a single digital ocean droplet, production and staging. I've installed queue supervisor according to the docs: sudo apt-get install supervisor and configured two configuration files inside /etc/supervisor/conf.d as follows:
laravel-worker.conf:
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app.com/artisan queue:work database --sleep=3 --tries=3
autostart=true
autorestart=true
user=root
numprocs=1
redirect_stderr=true
stdout_logfile=/var/www/app.com/worker.log
stopwaitsecs=3600
laravel-worker-staging.conf:
[program:laravel-worker-staging]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/test.app.com/artisan queue:work database --sleep=3 --tries=3
autostart=true
autorestart=true
user=root
numprocs=1
redirect_stderr=true
stdout_logfile=/var/www/test.app.com/worker.log
stopwaitsecs=3600
Once I'm done testing I will disable the server block for test.app.com to prevent random users to visit the site . Do I need to do anything with queue supervisor because it will still be running in the background for the test site or maybe the laravel-worker-staging.conf to prevent it from unnecessarily using up server resources?
Looks like I could just issue the following command:
supervisorctl stop laravel-worker-staging
I have supervisorctl managing some daemon queue workers with this configuration :
[program:jobdownloader]
process_name=%(program_name)s_%(process_num)03d
command=php /var/www/microservices/ppsatoms/artisan queue:work ppsjobdownloader --daemon --sleep=0
autostart=true
autorestart=true
user=root
numprocs=50
redirect_stderr=true
stdout_logfile=/mnt/##sync/jobdownloader.log
Sometimes some workers are like hanging (running but stop getting queue messages) and supervisorctl does not automatically restart them, so I have to monitor and manually restart them.
Is there something wrong with the configuration? What can I do to prevent this to happen in the future?
Update :
Run the process as normal process (non-daemon) so that supervisorctl can restart the workers after they signal exit code :
[program:jobdownloader]
process_name=%(program_name)s_%(process_num)03d
command=php /var/www/microservices/ppsatoms/artisan queue:work ppsjobdownloader --sleep=0
autostart=true
autorestart=true
user=root
numprocs=50
redirect_stderr=true
stdout_logfile=/mnt/##sync/jobdownloader.log