Cron vs systemd timer: hangisini kullanmalısınız?

Güncel bir dağıtımda, sahibi olduğunuz her iş için systemd timer kullanın; cron’u tek satırlık kullanıcı işlerine ve kendiniz kurmadığınız sunuculara bırakın. Timer’lar her çalıştırmayı journal’a loglar, makine kapalıyken kaçan takvimleri telafi edebilir ve sistemdeki her şey gibi aynı unit dosyalarına bağımlıdır. Cron kısalıkta kazanır — tek crontab -e satırı, iki unit dosyasını geçer — ve minimal konteynerlerde, egzotik Unix makinelerinde var olduğu garanti edilen tek zamanlayıcı olmayı sürdürür. Pazarlığın püf noktası şu: cron sessizce başarısız olur. İşiniz gece 3’te hata verirse cron, kimsenin okumadığı yerel bir posta kutusuna mail atar; timer ise size tam çıktıyla birlikte journalctl -u mytimer.service verir. Aşağıda: gerçek farklar, ikisinin nasıl test edileceği, bir timer’ın neden tetiklenmeyebileceği ve bir karar tablosu.

Cron ile systemd timer arasındaki fark nedir?

Cron, beş zaman alanı ve bir komuttan oluşan satırları okuyan, duvar saati eşleştiğinde her komutu çalıştıran bir daemon’dır. Modelin tamamı budur. “İş” diye bir nesnesi yoktur: unit yok, status yok, bağımlılık yok, kendine ait log kaydı yok.

Systemd timer ise takvimi eşleştiğinde başka bir unit dosyasını (foo.service) tetikleyen bir unit dosyasıdır (foo.timer). İş, herhangi bir servis gibi start, status, log ve hata izlemesi olan birinci sınıf bir nesnedir. Zamanlama ya takvim esaslıdır (cron benzeri) ya monotonic (OnBootSec=15min — duvar saati değişiklikleri bunu şaşırtamaz).

Pratik sonuçları:

• Loglama: timer’lar stdout/stderr’i unit başına journal’a yazar; cron en iyi ihtimalle yerel kullanıcıya mail atar.
• Kaçan çalıştırmalar: Persistent=true‘lu bir timer, takvimi kaçtıysa açılışta bir kez çalışır; cron yalnızca atlar.
• Bağımlılıklar: timer’lar network-online.target ya da mount noktalarını bekleyebilir; cron, yeniden deneme mantığını scriptin içinde elle yazmanızı ister.
• Sözdizimi: cron tek satır; timer iki dosya. Geçişin bütün maliyeti budur.

Hangi takvim sözdizimi daha kolay — crontab mı, OnCalendar mı?

Cron’un beş alanı, kompakt ve yerleşik olandır: */15 * * * * her 15 dakika demektir ve çoğu yönetici bunları uykusunda okur. Systemd’nin OnCalendar=‘i daha geveze ama kesinlikle daha anlatımlıdır; üstelik systemd-analyze calendar, kaydetmeden önce sonraki çalıştırmaları söyler — cron’un eşdeğeri bir dry-run yoktur.

# Cron: her gün 03:30'da
30 3 * * * /usr/local/bin/backup.sh

# systemd: aynı takvim, kaydetmeden önce doğrulanabilir
systemd-analyze calendar "*-*-* 03:30:00"
# -> Sonraki çalışma: Fri 2026-09-11 03:30:00 ...

OnCalendar, cron’un gerçekten temiz ifade edemediği şeyleri halleder: Mon..Fri *-*-* 09..17:00:00 (hafta içi, mesai saatleri) ya da binlerce makinenin aynı anda bir sunucuya yumruklanmasını önlemek için RandomizedDelaySec=10m ile birlikte *:0/15.

Systemd timer’ı beklemeden nasıl test edersiniz?

Üç komut her şeyi cevaplar. Nelerin planlandığını ve bir sonraki çalışmanın ne zaman olduğunu listeleyin, işi timer’ın yapacağı gibi elle çalıştırın, sonra loglarını okuyun:

systemctl list-timers --all                 # her timer, sonraki + son çalışma
sudo systemctl start backup.service         # işi şimdi tetikle, timer'ın kullandığı unit'in aynısı
journalctl -u backup.service -f             # çıktısını canlı izle

Bölünmeye dikkat edin: systemctl start backup.timer takvimi kurar; servis işin kendisidir. list-timers timer’ınızı gösteriyorsa, systemctl status backup.service yeşilse ve journal çıktınızı gösteriyorsa, zincirin tamamı çalışıyor demektir.

Bir cron işini elle nasıl çalıştırırsınız?

Cron işleri, silinmiş bir ortamla çalışır; “benim shell’imde çalışıyor, cron’da çalışmıyor” başlı başına bir hata türüdür. Cron’u sadakatle taklit etmek için komutu, cron’un kullanacağı ortamla sh üzerinden çalıştırın:

crontab -l                                  # tam satırı doğrula
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # cron tetikledi mi hiç? (Debian/Ubuntu)
journalctl -u cron -n 20                    # aynısı, systemd dağıtımlarında

O env -i satırı, işin dürüst manuel testidir: cron’un varsayılan PATH‘iyle çıplak bir ortam. Sessiz cron arızalarının çoğu ya çıplak bir PATH ya da komuttaki tırnaksız bir %‘dir (cron %‘i yeni satır sayar) ve ikisi de bu yolla hemen ortaya çıkar.

Systemd timer’ım neden tetiklenmiyor?

Dört sebep neredeyse her vakayı kapsar, kontrol sırasıyla:

1. Servis ile timer adları eşleşmiyor. foo.timer, foo.service‘i tetikler — yazım hatası bir OnFailure ya da adı değişmiş bir unit, timer’ın “boşa çalışması” demektir. systemctl cat foo.timer, neyi hedeflediğini tam olarak gösterir.
2. Timer düzenlendi ama reload edilmedi. Unit dosyasını değiştirdikten sonra: sudo systemctl daemon-reload && sudo systemctl restart foo.timer. Bu olmadan yeni takviminiz canlıda değildir.
3. Persistent=true‘nun OnCalendar tarafında beklemediğiniz bir semantiği vardır — ya da list-timers yerine systemctl status foo.timer‘a bakıyorsunuzdur (boşta bile hep active gösterir).
4. Tetiklediği servis anında çöküyordur, timer ölü görünür. journalctl -u foo.service --since -1h, list-timers‘ın sakladığı çöküşü gösterir.

Loglara baktığınızda, journalctl cheat sheet işi hızlandıran filtreleri (-u, --since, -f) anlatıyor.

Cron vs systemd timer: karar tablosu

	cron	systemd timer
Kurulum	tek crontab satırı	iki unit dosyası
Loglama	yerel posta, genelde okunmaz	journal, unit başına
Kaçan çalıştırma (makine kapalı)	atlanır	Persistent=true ile bir kez çalışır
Bağımlılıklar / sıralama	yok — script’te kendin yap	tam unit bağımlılıkları
Rastgele gecikme	$RANDOM ile DIY	RandomizedDelaySec=
Takvim testi/dry-run	yok	systemd-analyze calendar
Her yerde var	evet — konteynerler, BSD’ler, gömülü sistemler	systemd (PID 1) gerektirir
Root’suz kullanıcı işleri	crontab -e	systemd --user unit’leri

Pratik kurallar: kendi systemd makinenize iş taşıyorsunuz → timer. Hızlı bir kişisel hatırlatıcı ya da kurmadığınız bir kutu → cron. Bağımlılığı, yeniden denemesi ya da gerçekten çalışıp çalışmadığını bilme ihtiyacı olan her şey → her zaman timer. Sık görülen desen, bakım işi çalıştıran bir timer’dır — diyelim ki gecelik bir rsync backup — Persistent=true, planlanan dakikada makine uyuyorsa bile yedeğin alınmasını garanti eder; bunu cron hiçbir şekilde sunamaz.