Zamanlanmış görevlerin en tehlikeli özelliği şudur: başarısız olduklarında hiçbir şey olmaz. Sayfa açılmaz hatası vermez, kimse şikayet etmez. Yedekleme haftalardır çalışmıyordur, siparişler muhasebeye aktarılmıyordur, önbellek temizlenmiyordur — ve bunu ancak sonuçları görünür hale geldiğinde fark edersiniz.
Bu rehber, kendi sanal sunucunuz üzerinde zamanlanmış görevleri güvenilir biçimde kurmayı ve izlemeyi anlatıyor.
Cron'un Klasik Beş Tuzağı
1. Farklı Ortam Değişkenleri
Zamanlanmış görevler, sizin oturumunuzdan çok daha dar bir ortamda çalışır. Komut satırında sorunsuz çalışan bir betik, cron altında "komut bulunamadı" hatası verebilir çünkü arama yolu farklıdır.
Çözüm: Görevlerde her zaman tam yol kullanın. Yorumlayıcıyı da tam yoluyla belirtin — özellikle sunucuda birden fazla sürüm kuruluysa.
2. Yanlış Çalışma Dizini
Görev, betiğin bulunduğu dizinde değil kullanıcının ana dizininde başlar. Göreli yol kullanan bir betik dosyalarını bulamaz.
Çözüm: Betiğin başında çalışma dizinini açıkça belirleyin ya da tüm yolları mutlak yazın.
3. Farklı Yorumlayıcı Sürümü
Web istekleri bir sürümle, zamanlanmış görevler başka bir sürümle çalışabilir. Bu, "site çalışıyor ama cron hata veriyor" durumunun en yaygın nedenidir ve teşhisi zordur çünkü kod aynıdır.
Çözüm: Görev komutunda sürümü açıkça belirtin, sistem varsayılanına güvenmeyin.
4. Çıktının Kaybolması
Görevin ürettiği hata mesajları hiçbir yere yazılmıyorsa, başarısızlık tamamen görünmez olur.
Çözüm: Her görevin çıktısını bir log dosyasına yönlendirin — hem standart çıktıyı hem hata çıktısını. Bu tek değişiklik, teşhis edilemeyen sorunların çoğunu görünür kılar.
5. Üst Üste Binen Çalıştırmalar
Beş dakikada bir çalışan bir görev, altı dakika sürüyorsa ikinci kopya birincisi bitmeden başlar. Zamanla onlarca kopya birikir, sunucu tükenir ve veri bozulabilir.
Çözüm: Kilit mekanizması kullanın — görev başlarken bir kilit alsın, çalışan bir kopya varsa yeni kopya sessizce çıksın.
Sessiz Başarısızlığı Yakalamak
Yukarıdaki tuzakları kapatmak yeterli değil; görevin çalıştığını da doğrulamanız gerekir. Üç yaklaşım vardır ve etkileri farklıdır:
| Yöntem | Yakaladığı | Kaçırdığı |
|---|---|---|
| Hata durumunda e-posta | Hata veren çalıştırmalar | Hiç çalışmayan görev |
| Log dosyası | Hata detayı | Kimse okumazsa hiçbir şey |
| Kalp atışı izleme | Hiç çalışmayan görev | — |
Kritik fark üçüncü satırdadır. İlk iki yöntem yalnızca görev çalışıp hata verdiğinde sizi uyarır. Görev hiç tetiklenmiyorsa — zamanlama yanlış yazılmış, kullanıcı silinmiş, servis durmuş — hiçbir hata üretmez ve tamamen sessiz kalır.
Kalp atışı yaklaşımı bunu tersine çevirir: görev her başarılı tamamlanışında bir işaret bırakır, izleme sistemi de beklenen sürede işaret gelmezse uyarı verir. Yani "hata oldu" yerine "olması gereken olmadı" sinyali alırsınız. Kritik görevler için tek güvenilir yöntem budur.
Görevleri Doğru Tasarlamak
- Yeniden çalıştırılabilir yazın. Aynı görev iki kez çalışırsa zarar vermemeli. Bir görev "son işlemden bu yana gelenleri işle" mantığıyla yazılırsa, kaçırılan bir çalıştırma bir sonrakinde telafi edilir.
- Uzun işleri parçalayın. Saatlerce süren tek bir görev yerine, her turda sınırlı sayıda kayıt işleyen kısa görevler kurun. Böylece bir çalıştırma başarısız olsa bile ilerleme kaybolmaz.
- Yoğun saatlerden kaçının. Ağır görevleri trafiğin düşük olduğu saatlere alın. "Her akşam belirli bir saatte site yavaşlıyor" şikayetinin nedeni genellikle o saatte çalışan bir görevdir.
- Aynı dakikaya yığmayın. Tüm görevleri saat başına kurmak, o dakikada ani bir yük sıçraması üretir. Birkaç dakika kaydırarak dağıtın.
- Saat dilimini doğrulayın. Sunucunun saat dilimi beklediğinizden farklıysa, gece yarısı çalışması gereken görev öğlen çalışır.
Web Tabanlı Cron'un Sorunu
Bazı uygulamalar zamanlanmış görevleri gerçek bir sistem görevi yerine, siteye gelen ziyaretçi isteklerine bağlar. Bu yaklaşımın üç zaafı vardır:
- Trafik yoksa görev hiç çalışmaz — gece yarısı ziyaretçi gelmezse yedekleme alınmaz.
- Görev, bir ziyaretçinin isteği içinde çalıştığı için o ziyaretçinin sayfası yavaşlar.
- Zaman aşımı sınırlarına takılır; uzun görevler yarıda kesilir.
Kendi sunucunuz varsa bu yaklaşımı kullanmak için hiçbir neden yoktur. Uygulamanın web tabanlı zamanlayıcısını kapatıp gerçek bir sistem görevi tanımlayın — bu, paylaşımlı barındırmadan bir VDS ortamına geçmenin somut kazançlarından biridir.
Görev Envanteri Tutun
Zamanla biriken görevler yönetilemez hale gelir: hangi görev ne yapıyor, kim ekledi, hâlâ gerekli mi? Basit bir tablo tutun — görev adı, ne yaptığı, sıklığı, sahibi ve log dosyası nerede. Sunucu taşırken veya bir sorun araştırırken en çok bu tabloya ihtiyaç duyarsınız.
Sonuç
Zamanlanmış görevlerde asıl risk hata değil sessizliktir. Tam yol kullanmak, çıktıyı loglamak ve kilit mekanizması kurmak klasik tuzakları kapatır; ancak kritik görevler için bunlar yetmez — çalışmadığında haber veren bir kalp atışı izlemesi gerekir. Yedekleme göreviniz için bu izlemeyi kurmak, yedeklemenin kendisini kurmak kadar önemlidir.
Sıkça Sorulan Sorular (SSS)
Cron görevim çalışmıyor, nereden başlamalıyım?
Önce çıktıyı bir log dosyasına yönlendirin ve bir sonraki çalıştırmayı bekleyin. Log boşsa görev hiç tetiklenmiyordur — zamanlama ifadesini ve servisin çalıştığını kontrol edin. Log hata içeriyorsa, en olası nedenler tam yol eksikliği veya yanlış yorumlayıcı sürümüdür.
Sitem çalışıyor ama cron farklı sürüm kullanıyor, neden?
Web istekleri web sunucusunun yapılandırdığı sürümle, zamanlanmış görevler sistem varsayılanıyla çalışır. Bunlar farklı olabilir. Çözüm, görev komutunda yorumlayıcının tam yolunu açıkça yazmaktır.
Görevlerin üst üste binmesini nasıl engellerim?
Kilit mekanizması kullanın: görev başlarken bir kilit alsın, çalışan bir kopya varsa yeni kopya hiç başlamadan çıksın. Uzun süren görevlerde bu, sunucu tükenmesini önleyen en önemli önlemdir.
Kalp atışı izlemesi karmaşık mı?
Hayır — görevin sonuna, başarıyla tamamlandığında bir işaret bırakan tek bir satır eklemek yeterlidir. İzleme tarafı da beklenen sürede işaret gelip gelmediğine bakar. Kurulumu kısadır ve hiç çalışmayan bir görevi yakalayan tek yöntemdir.
