cron Yerine systemd Zamanlayıcıları Neden Daha İyi

Linux'ta iş zamanlayan herkes cron'a uzanır ve kelime, her türlü zamanlanmış çalıştırmanın ortak adı hâline gelmiştir. Mayıs 2026'da tjll.net'in yazarı, 2026'da gerçek anlamda cron daemon'ının ve daha modern kuzenlerinin yanlış araç olduğunu, systemd zamanlayıcısının ise gördüğünden daha fazla sevgiyi hak ettiğini savunuyor.

cron'a karşı argümanlar

İtirazları ideolojik değil pratik. Belirsiz $PATH ayarları cron betiklerinin çalışmasını öngörülemez kılıyor. stdout ve stderr çoğu zaman bir kara delikte kayboluyor ya da ana makinenin posta sistemine düşüyor; bu da neredeyse hiç istenen şey değil. Çalıştırma geçmişini izlemek ve sorgulamak zor. Kimilerinin gurur kaynağı olan zamanlama dilbilgisi ise okunması kolay değil: `01,31 04,05 1-15 1,6 *` gibi bir ifadeyi çözmek gerçek çaba istiyor. Yazar, zamanlayıcıların tüm bu sorunları ve fazlasını çözdüğünü yazıyor.

Bir servis, bir zamanlayıcı ve bir program

systemd zamanlayıcısı, başka bir unit'i — genellikle bir servisi — zamanlayan bir unit türüdür. Makalenin örneği, makineyi kapatma şansı onda bir olan bir servis ve /etc/systemd/system içinde aynı ad kökünü paylaşan bir zamanlayıcı dosyası; çünkü zamanlayıcının varsayılan Unit= ayarı eşleşen .service dosyasını seçer. .timer'ı başlatmak onu saate alır ama hedefi çalıştırmaz; enable etmek ise WantedBy=timers.target kurulum hedefi üzerinden açılışta devreye girmesini sağlar. İki ayrıntı insanları yanıltıyor: ExecStart varsayılan olarak bir shell üzerinden çalışmaz, dolayısıyla boru hatları yazıldığı gibi işlemez ve sistem yöneticisinin varsayılanlarının ötesinde ortam değişkeni devralmaz.

Takvim olayları ve zaman aralıkları

cron'a kıyasla en büyük kavramsal sıçrama, systemd'nin iki tür program sunmasıdır. Biri tanıdık takvim olayı — daily ya da tam biçimi `*-*-* 00:00:00` — diğeri ise önceki bir olaya göre ölçülen zaman aralığı; örneğin OnBootSec=1h ile OnUnitActiveSec=1h, açılıştan bir saat sonra ve ardından her çalışmadan bir saat sonra tetiklenir. İkinci biçim çoğu zaman gerçek niyete denk düşer: geçici bir dizini temizleyen bir işin açılıştan hemen sonra çalışması pek işe yaramaz; API'yi saate göre tam on beş dakikada bir yoklayan bir bot ise, zaman aralığına dayalı programın kaçındığı trafik tepesini yaratır. Yazar ilk kaynak olarak systemd.time kılavuzunu ve ifadeleri doğrulayıp açıklayan, klasik cron joker karakterlerini bile çözebilen systemd-analyze calendar'ı öneriyor.

cron'un sunamadığı özellikleri de ayrıca sayıyor: sırada neyin çalışacağını ve en son neyin çalıştığını tek tabloda gösteren list-timers; askıdaki makineyi bir işi çalıştırmak için uyandıran WakeSystem=; "thundering herd" tepelerini önlemek için çalıştırmaları yayan FixedRandomDelay= ve RandomizedOffsetSec=; ve kaçırılan bir çalıştırmayı zamanlayıcı yeniden etkin olur olmaz tetikleyen Persistent= — kapalı kalmış bir dizüstünde yapılandırma yönetimi kontrolü için kullanışlı. systemctl --user ile çalışan kullanıcı düzeyi zamanlayıcılar da aynı ölçüde geçerli, ancak kurulum hedefinin bazen default.target olması gerekir. Saatin yine doğru olması şart ve timedatectl timesync-status bunun böyle olup olmadığını gösteriyor.