Cron vs systemd Timer: Hangisine Ne Zaman Yöneliyorum
Bu konu her açıldığında, biri systemd timer'ların cron'u tamamen değiştirmesi gerektiğini söylüyor. Yetenekler konusunda yanılmıyorlar, timer'ların logging'i daha iyi, başka unit'lere bağımlı olabiliyorlar, ve job'ın çalışması gereken saatte sunucu kapalıysa bunu atlamıyorlar. Yine de düzenli olarak cron job yazmaya devam ediyorum, çünkü seçim gerçekten feature'lar üzerinden yapılmıyor. Mesele, bunu bir yıl sonra kimin okuyacağı, ve job'ın gerçekte ne kadar tören hak ettiği.
Cron'un kazandığı yer: küçük, basit, herkesin bildiği
Bir cron job'ı bir satır. Son yirmi yılda Linux'a dokunmuş herkes bir crontab'ı dokümantasyona gerek kalmadan okuyup anlayabilir:
# /etc/cron.d/cleanup-tmp
0 3 * * * root find /tmp -type f -atime +7 -delete
Bu dosyaların sağladığı ekstra capability'lerin hiçbirine ihtiyaç duymayan bu tür bir job için bile, systemd karşılığı iki dosya demek: bir .service ve bir .timer, üstüne bir enable adımı. Buradaki overhead asıl olarak yazmakla ilgili değil, bir incident sırasında bu job'ı bulmak zorunda kalacak bir sonraki kişiyle ilgili. crontab -l ya da /etc/cron.d/'ye hızlı bir bakış, çoğu Linux admin'in ilk kontrol ettiği şey. Kimsenin aramayı bilmediği bir timer, biri ona çarpana kadar pratikte var olmayan bir job demek.
Kuralım şu: job tek bir komutsa, failure'a tepki vermesi gerekmiyorsa, ve atlanmış bir run önemli olmayacaksa, bu cron.
systemd timer'ların kazandığı yer: güvenilmesi gereken her şey
Zamanlanmış bir job gerçekten önem kazandığı an, backup'lar, sertifika renewal'ları, sessiz bir failure'ın gece 2'de bir page'e dönüştüğü her şey, systemd timer'ların ekstra setup'ı kendini kanıtlıyor.
# /etc/systemd/system/backup.service
[Unit]
Description=Nightly database backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup nightly
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
[Install]
WantedBy=timers.target
systemctl enable --now backup.timer
journalctl -u backup.service
Burada cron'un bedavaya vermediği üç şey var. journalctl -u backup.service, her run'ın tam output'unu ve exit status'unu gösteriyor, bir log dosyasına redirect edip rotate etmeyi hatırlamayı ummaya gerek yok. Persistent=true, sunucu gece 2'de kapalıysa job'ın bir sonraki günü sessizce beklemek yerine sunucu açılır açılmaz çalışması demek. Ve systemctl status backup.timer, job'ın son ne zaman çalıştığını ve sıradaki çalışmanın ne zaman olduğunu tam olarak söylüyor, bir cron job'ında ise bu schedule'ı okuyup hesabı kendiniz yapmanız demek.
Asıl belirleyici soru
Yeni bir zamanlanmış task kurarken soru "hangisi daha modern" değil. Soru şu: bu job sessizce fail ederse, biri fark edene kadar ne kadar geçer, ve bu önemli mi?
Cevap "gerçekten önemli değil, ve önemli olsaydı zaten başka bir şekilde fark ederdim" ise (bir tmp cleanup, bir cache warm-up, zaten logrotate'in de kapsadığı bir log rotation), cron fazlasıyla yeterli, ve basitliği bir limitasyon değil bir feature. Cevap "bu, bizimle data loss arasındaki tek şey" ya da "burada atlanan bir run müşteriye yansıyan bir probleme dönüşüyor" ise, systemd timer'ın getirdiği o iki ekstra dosya ve düzgün logging her zaman buna değiyor.
Yönettiğim sunucuların çoğu sonunda ikisini de barındırıyor, ev işleri için bir avuç cron one-liner'ı, ve gerçekten güvenilmesi gereken job'lar için az sayıda systemd timer. Bu karışım bir uzlaşma değil, aracın törenini job'ın önemine eşliyor, ve bu da bir kutudaki systemd timer'ların scroll'layıp geçilen bir gürültü yerine kısa, anlamlı bir liste olmasını sağlıyor.