Cron (Zamanlanmış Görev) Nedir?

Crontab satırını okumak

Cron, arka planda sürekli çalışan bir servistir (cron daemon). Her dakika crontab dosyalarına bakar ve zamanı gelen komutları çalıştırır. Kullanıcıların kendi tabloları crontab -e ile düzenlenir. Her satır beş zaman alanı ve bir komuttan oluşur:

# dk  saat gün ay hafta  komut
30    3    *   *  *      /usr/local/bin/yedek-al.sh
*/15  *    *   *  *      /usr/bin/node /srv/app/scripts/sitemap-yenile.js
0     9    *   *  1-5    /srv/app/bin/gunluk-rapor
0     0    1   *  *      /srv/app/bin/aylik-fatura

İlk satır her gece 03:30'da yedek alır; ikincisi her 15 dakikada bir çalışır; üçüncüsü hafta içi her sabah 09:00'da; dördüncüsü her ayın ilk günü gece yarısı. Yıldız “her değer”, */15 “15'te bir”, 1-5 aralık, 1,15 liste anlamına gelir. Birçok cron sürümü @daily, @hourly ve sistem açılışında çalışan @reboot gibi kısaltmaları da kabul eder.

Sık yapılan bir yanlış: ayın günü ve haftanın günü alanlarının ikisi de kısıtlanırsa cron bunları “ve” ile değil “veya” ile birleştirir. 0 4 1,15 * 5 satırı, ayın 1'i ve 15'inde ve ayrıca her cuma çalışır; “1'i veya 15'i cumaya denk gelirse” anlamına gelmez.

Saat dilimi tuzakları

Cron, zamanı sunucunun saat dilimine göre yorumlar. Bulutta ve VPS'lerde sunucular çoğu zaman UTC ile kurulur; bu durumda 0 3 * * * satırı Türkiye saatiyle 06:00'da çalışır. “Gece 3'te çalışsın” diye yazılan bir görevin mesai başlangıcına kayması bu yüzden sık görülen bir sorundur.

Yaz saati uygulayan bölgelerde ikinci bir tuzak vardır. crontab(5) kılavuzu, saatlerin ileri alındığı gece “var olmayan” saatlere planlanan görevlerin hiç çalışmayacağını, geri alındığı gece iki kez yaşanan saatlerdeki görevlerin ise iki kez çalışabileceğini belirtir. Türkiye 2016'dan beri yıl boyu UTC+3 kullandığı için yerel saatle çalışan sunucularda bu sorun yaşanmaz; ama Avrupa veya ABD saatine göre planlanan işlerde yaşanır.

• Sunucuları UTC'de tutup zamanlamayı UTC'ye göre yazmak, en az sürpriz üreten yaklaşımdır.
• Bazı cron sürümleri (ör. cronie) crontab içinde CRON_TZ değişkeniyle saat dilimi belirtmeyi destekler; her sürüm desteklemez.
• Kubernetes CronJob nesnelerinde saat dilimi, v1.27'den beri kararlı olan .spec.timeZone alanıyla verilir; belirtilmezse kontrol düzleminin yerel saati kullanılır.

Sessizce başarısız olan görevler

Cron bir komutu başlatır ama sonucuyla ilgilenmez. Görev aylarca hata verip kimse fark etmeyebilir. Nedenleri genellikle şunlardır:

• Kısıtlı ortam: Cron, oturum açmış kullanıcının kabuk ayarlarını yüklemez; PATH dardır ve ortam değişkenleri eksiktir. Komutlarda tam yol kullanmak ve gereken değişkenleri betikte tanımlamak gerekir.
• Kaybolan çıktı: Çıktı yerel posta kutusuna gider veya hiçbir yere gitmez. Standart çıktıyı ve hatayı bir log dosyasına yönlendirmek ya da merkezi loglamaya göndermek gerekir.
• Hiç çalışmama: Sunucu kapalıysa veya cron servisi durmuşsa hata mesajı bile oluşmaz. Görevin bittiğinde bir izleme adresine “çalıştım” sinyali göndermesi (heartbeat) ve sinyal gelmediğinde alarm üretilmesi bu boşluğu kapatır.

Üst üste binme ve birden çok sunucu

Beş dakikada bir çalışan görev bir gün yedi dakika sürerse, ikinci kopya ilki bitmeden başlar. Aynı kayıtları iki süreç birden işleyebilir. Linux'taki flock aracı bunu basitçe önler:

*/5 * * * * flock -n /tmp/senkron.lock /srv/app/bin/senkron >> /var/log/senkron.log 2>&1

Uygulama birden fazla sunucuda çalışıyorsa her sunucunun crontab'ı aynı görevi ayrı ayrı tetikler. Çözüm, zamanlanmış görevleri tek bir sunucuya atamak, dağıtık bir kilit kullanmak veya zamanlamayı bir iş kuyruğunun tekrarlanan iş özelliğine devretmektir. Hangi yol seçilirse seçilsin, görevin iki kez çalışması zarar vermemelidir; yani idempotent yazılmalıdır.