Belirti
Raporlar gelmez, eski kayıtlar temizlenmez, bir eşitleme geride kalır. Ne istisna vardır ne başarısız iş, çünkü hiçbir şey çalışmamıştır.
Kendiniz denetleyin
Cron satırını arayın ve içindeki yolun sitenin bugünkü klasörü olduğundan emin olun:
grep -rs "schedule:run" /etc/cron.d /var/spool/cron/crontabs
sudo -u <site kullanıcısı> crontab -lSonra uygulamanın neyi çalıştırmayı beklediğine bakın:
php artisan schedule:listGörevler listeleniyor ama bu klasör için çalışan bir cron satırı yoksa zamanlayıcı çalışmıyordur. cd ya da artisan yolu artık olmayan bir satır her dakika /dev/null'a, sessizce hata verir.
Nasıl oluyor
Yönettiğimiz bir sunucuda bir sitenin klasörünün adı değişti. Tek zamanlayıcı cron satırı eski yolu göstermeye devam etti ve zamanlayıcı biri fark edene kadar beş hafta durdu. Aynı yoldan cron ile başlatılan bir işçi de onunla birlikte durdu.
Düzeltme
Sitenin kullanıcısıyla, sitenin kullandığı PHP sürümü ve gerçek yolla tek bir cron satırı ekleyin:
* * * * * php8.4 /home/shop/shop.example.com/artisan schedule:run >> /dev/null 2>&1- Uygulama başına tek zamanlayıcı: iki satır her görevi iki kez çalıştırır. Önce ölü satırı silin, sonra yenisini ekleyin.
- Uzun süre durmuş bir zamanlayıcıyı başlatmadan önce
php artisan schedule:listçıktısını okuyun: listedeki her şey bir dakika içinde yeniden çalışmaya başlar. - Cron yerine
php artisan schedule:workçalıştıran bir supervisor programı da aynı işi görür.
Hostio nasıl bulur
Tarama kodunuzun tanımladığı zamanlanmış görevleri sayar (routes/console.php, bootstrap/app.php, app/Console/Kernel.php) ve sitenin klasörü için çalışan bir schedule:run cron satırı ya da schedule:work programı arar. Zamanlayıcısı olmayan görevler scheduler_missing tehlike bulgusunu açar.
Pro'da sitenin Cron jobs sekmesindeki Laravel scheduler hazır ayarı tam bu satırı, önizlemeden sonra yazar; Hostio aynı site için ikinci bir zamanlayıcıyı reddeder. Bir sitenin bilerek zamanlayıcısı yoksa bulguyu gerekçesiyle susturun.