Cron mu, systemd Timers mı: Hangisini Ne Zaman Kullanıyorum?

Bu konu ne zaman açılsa, birileri çıkıp systemd timer'larının cron'un tamamen yerini alması gerektiğini savunur. Özellikler konusunda haksız da sayılmazlar: timer'ların loglaması çok daha iyidir, diğer servislere bağımlılık tanımlayabilirsiniz ve sunucu kapalıyken kaçan bir görevi açılışta tekrar çalıştırabilirler. Yine de hala düzenli olarak cron job yazıyorum. Çünkü olay sadece özellikler değil; olay, yazdığınız bu kodu bir yıl sonra kimin okuyacağı ve görevin ne kadar "tören" hak ettiğiyle ilgili.

Cron'un kazandığı yerler: küçük, basit, bilindik

Bir cron görevi tek bir satırdan ibarettir. Son yirmi yıl içinde Linux'a eli değmiş herkes bir crontab dosyasını okuyup anında ne işe yaradığını anlayabilir:

# /etc/cron.d/cleanup-tmp
0 3 * * * root find /tmp -type f -atime +7 -delete

Bunun gibi görevler için systemd tarafındaki karşılık, iki ayrı dosya (bir .service ve bir .timer) yazıp bir de enable komutu çalıştırmaktır. Bu kadar basit bir işlem için inanılmaz bir zaman kaybı. Buradaki asıl sorun kod yazmak değil, keşfedilebilirliktir. Bir olay (incident) anında çoğu sistem yöneticisinin ilk bakacağı yer crontab -l veya /etc/cron.d/ dizinidir. Kimsenin bakmayı akıl etmediği bir systemd timer'ı, kimsenin haberi olana kadar pratikte yok hükmündedir.

Benim kuralım basit: Eğer görev tek bir komuttan ibaretse, hata yönetimi gerektirmiyorsa ve bir çalışmayı kaçırmasının hiçbir önemi yoksa, cron kullanırım.

systemd Timer'ların kazandığı yerler: güvenmeniz gereken her şey

Eğer zamanlanmış bir görev gerçekten önemliyse—yedeklemeler, sertifika yenilemeleri veya sessizce patladığında gece 2'de uyandırılmanıza sebep olacak herhangi bir şey—systemd timer'ları o fazladan zahmetin hakkını verir.

# /etc/systemd/system/backup.service
[Unit]
Description=Gece veritabanı yedeği

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Yedeği her gece çalıştır

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl enable --now backup.timer
journalctl -u backup.service

systemd burada cron'un asla veremeyeceği üç şey sunar:

1. journalctl -u backup.service komutuyla her çalışmanın tam çıktısını ve çıkış durumunu (exit status) görebilirsiniz. Çıktıyı bir log dosyasına yönlendirip logrotate'in patlamaması için dua etmenize gerek kalmaz.
2. Persistent=true parametresi sayesinde, sunucu o gece saat 2'de kapalıysa bile açıldığı anda kaçan görevi çalıştırır.
3. systemctl status backup.timer komutuyla görevin en son ne zaman çalıştığını ve bir sonraki sefer ne zaman çalışacağını saniyesi saniyesine görebilirsiniz.

Karar verdirici soru

Yeni bir zamanlanmış görev ayarlarken "hangisi daha modern" diye düşünmem. Şunu sorarım: Eğer bu görev sessizce patlarsa, birisinin fark etmesi ne kadar sürer ve bu durum ne kadar umurumuzda olur?

Eğer cevap "pek de umurumuzda olmaz" ise (geçici dosya temizliği, önbellek ısıtma vs.), cron'un basitliği bir kısıtlama değil, bir özelliktir. Ama eğer bu görev işletme ile veri kaybı arasındaki tek engelse, systemd timer'ının getirdiği o fazladan iki dosya ve loglama altyapısı tartışılmaz bir zorunluluktur.

Yönettiğim çoğu sunucuda ikisi bir arada çalışır: temizlik işleri için birkaç satırlık cron görevleri ve gerçekten güvenilmesi gereken işler için kısa bir systemd timer listesi. Bu bir taviz değil, aracı amaca uydurmaktır.