Laravel’de mail veya arka plan işi kuyruğa düşüyor ama sayfa yenilenmeden çalışmıyorsa genellikle worker süreci açık değildir. Terminalde php artisan queue:work çalıştırınca düzelip SSH bağlantısı kapanınca tekrar durması da aynı sorunun işaretidir.
Üretimde worker’ı terminal oturumuna bağlı bırakmak yerine Supervisor gibi bir süreç yöneticisi kullanıyorum. Ubuntu’da kurulum:
sudo apt update
sudo apt install supervisorÖrnek /etc/supervisor/conf.d/laravel-worker.conf dosyası:
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=/usr/bin/php /var/www/proje/artisan queue:work --sleep=3 --tries=3 --timeout=120
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/proje/storage/logs/worker.log
stopwaitsecs=3600Yolları ve kullanıcıyı kendi sunucunuza göre düzenledikten sonra:
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl statusWorker çalışıyor göründüğü halde işler ilerlemiyorsa .env içindeki QUEUE_CONNECTION değerini ve ilgili sürücüyü kontrol etmek gerekiyor. Database queue kullanılıyorsa jobs tablosu, Redis kullanılıyorsa bağlantı ve parola ayarları doğru olmalı. Yapılandırma değiştirdikten sonra eski cache yüzünden worker hâlâ önceki değeri kullanabilir:
php artisan optimize:clear
php artisan queue:restartDeploy sırasında queue:restart çalıştırmak önemli. Queue worker uzun yaşayan bir PHP sürecidir; yeni kodu her istekte yeniden yüklemez. Restart sinyali mevcut işi güvenli biçimde tamamladıktan sonra sürecin yenilenmesini sağlar, Supervisor da tekrar ayağa kaldırır.
Başarısız işleri görmek için:
php artisan queue:failed
php artisan queue:retry allRetry yapmadan önce gerçek hatayı logdan düzeltmek gerekir; aksi halde aynı iş tekrar tekrar düşer. timeout, retry_after ve işin kendi çalışma süresi birbiriyle uyumlu olmalı. Aksi durumda aynı job iki kez işlenebilir.
cPanel ortamında Supervisor erişimi yoksa cron ile queue:work --stop-when-empty çalıştırmak geçici bir seçenek olabilir, fakat yoğun sistemlerde gerçek process manager daha güvenilir.
Queue süreçlerini yalnızca “running” durumuyla takip etmek yeterli değil. Kuyrukta bekleyen iş sayısı, en eski işin yaşı ve failed job artışı için alarm kurmak gerekiyor. Worker çalışıyor görünürken belirli bir job sonsuz retry döngüsüne girebilir. İşleri idempotent tasarlamak, aynı ödeme veya bildirim görevinin iki kez çalışması halinde veri bozulmasını önleyen önemli bir güvenlik ağıdır.
Siz queue için Redis mi database sürücüsü mü kullanıyorsunuz? Worker durduğunda Supervisor logunda hangi hata görünüyor?
Cevaplar
0 yanıt