Linux'ta Cron: Zamanlanmış Görevler Rehberi

Linux'ta Cron: Zamanlanmış Görevler Rehberi

Bir sunucuyu yönetirken tekrar eden işlerin çoğu aslında insan müdahalesi gerektirmez: log dosyalarını temizlemek, veritabanını yedeklemek, disk doluluğunu kontrol etmek, önbelleği temizlemek... Bu işleri her seferinde elle çalıştırmak yerine Linux'un onlarca yıldır güvenilir şekilde kullanılan zamanlayıcısı cron devreye girer. Bu yazıda cron'un nasıl çalıştığını, crontab söz dizimini, sistem genelindeki cron dizinlerini, log takibini ve üretim ortamında sık yapılan hataları uygulamalı örneklerle ele alıyoruz.

Cron Nedir, Ne İşe Yarar?

Cron, Linux ve Unix tabanlı sistemlerde arka planda çalışan bir zamanlayıcı servistir (daemon). Sistem başlangıcında crond (bazı dağıtımlarda cron) servisi olarak ayağa kalkar ve her dakika kendi tanım dosyalarını (crontab'ları) kontrol ederek zamanı gelen komutları çalıştırır.

Cron'un temel mantığı basittir: "şu dakikada, şu saatte, şu günde, şu ayda, haftanın şu gününde şu komutu çalıştır" şeklinde bir kural listesi tutar. Servis her dakika uyanır, mevcut zaman bu kurallardan herhangi biriyle eşleşiyorsa ilgili komutu çalıştırır ve tekrar uykuya döner.

Sunucu yönetiminde cron'un en yaygın kullanım alanları şunlardır:

• Veritabanı ve dosya yedeklerini otomatikleştirmek
• Log dosyalarını döndürmek veya eski kayıtları temizlemek
• SSL sertifikası yenileme kontrolleri yapmak
• Disk kullanımı, bellek veya servis durumu gibi metrikleri periyodik olarak raporlamak
• Bakım scriptlerini (önbellek temizleme, geçici dosya silme) belirli aralıklarla tetiklemek

Büyükweb notu: VDS üzerinde barındırdığınız her uygulamanın kendine özgü bakım ihtiyacı vardır. Yönettiğiniz sunucularda cron ile otomasyon kurmak, hem insan hatasını azaltır hem de gece yarısı manuel müdahale ihtiyacını ortadan kaldırır. Kendi zamanlanmış görevlerinizi tam kontrol altında çalıştırabileceğiniz bir ortam arıyorsanız VDS Sunucu paketlerimize göz atabilirsiniz.

Crontab Söz Dizimi: Beş Alanlı Zaman Yapısı

Cron görevleri crontab (cron table) dosyalarında tanımlanır. Her satır beş zaman alanı ve ardından çalıştırılacak komuttan oluşur:

# Dakika Saat GünAy Ay HaftaGünü Komut
# (0-59) (0-23) (1-31) (1-12) (0-7, 0 ve 7=Pazar)
  *      *      *      *     *      /path/to/script.sh

Alanları soldan sağa şöyle okuyabilirsiniz:

Alan	Değer Aralığı	Açıklama
Dakika	0-59	Saatin hangi dakikasında
Saat	0-23	Günün hangi saatinde (24 saat formatı)
Ayın günü	1-31	Ayın hangi günü
Ay	1-12	Yılın hangi ayı
Haftanın günü	0-7	0 ve 7 Pazar, 1 Pazartesi... 6 Cumartesi

Her alanda kullanabileceğiniz özel karakterler:

• * — "her değer" anlamına gelir (örneğin dakika alanında * her dakika demektir)
• , — birden fazla değeri listelemek için (1,15 gibi ayın 1'i ve 15'i)
• - — bir aralık belirtmek için (9-17 gibi 09:00-17:00 arası)
• / — adım değeri belirtmek için (*/15 gibi her 15 dakikada bir)

Birkaç somut örnek:

# Her gece saat 02:00'de yedekleme scriptini çalıştır
0 2 * * * /usr/local/bin/backup.sh

# Her 15 dakikada bir sağlık kontrolü yap
*/15 * * * * /usr/local/bin/healthcheck.sh

# Her Pazartesi saat 09:00'da haftalık rapor gönder
0 9 * * 1 /usr/local/bin/weekly-report.sh

# Her ayın 1'inde ve 15'inde saat 03:30'da log arşivle
30 3 1,15 * * /usr/local/bin/archive-logs.sh

# Mesai saatleri içinde (09-18) her saat başı çalıştır
0 9-18 * * 1-5 /usr/local/bin/business-hours-task.sh

Zaman ifadelerini yazarken sık yapılan bir hata, alanların sırasını karıştırmaktır. Dakika her zaman ilk alandır, saat ikinci alan gelir — çoğu hatalı çalışan cron görevinin kök nedeni budur.

Crontab Komutları: Oluşturma, Listeleme, Silme

Her kullanıcının kendine ait bir crontab dosyası olabilir. Bu dosyayı doğrudan düzenlemek yerine crontab komutunu kullanmanız önerilir, çünkü komut sözdizimi hatalarını uyarır ve dosyayı doğru şekilde kaydeder.

# Mevcut kullanıcının crontab'ını düzenle
crontab -e

# Mevcut kullanıcının crontab görevlerini listele
crontab -l

# Belirli bir kullanıcının crontab'ını listele (root yetkisi gerekir)
crontab -u www-data -l

# Crontab'ı tamamen sil
crontab -r

crontab -e çalıştırıldığında sistem varsayılan metin editörünüzü açar (genellikle nano veya vi). SSH üzerinden sunucuya bağlanıp bu komutu çalıştıracaksanız ve terminal komutlarına henüz alışkın değilseniz, önce Linux SSH Terminal Komutları yazımıza göz atmanız işinizi kolaylaştırır. Editör seçimini değiştirmek isterseniz EDITOR ortam değişkenini export EDITOR=vim şeklinde ayarlayabilir veya doğrudan vim ile çalışmayı tercih edenler için Vim Metin Editörü Hızlı Başlangıç Rehberi faydalı bir kaynaktır.

Crontab dosyasına yeni bir satır eklediğinizde herhangi bir servisi yeniden başlatmanıza gerek yoktur — cron daemon dosyadaki değişiklikleri otomatik olarak algılar.

Özel Zamanlama İfadeleri (@daily, @reboot vb.)

Beş alanlı zaman yazımı yerine bazı kısayol ifadeler de kullanılabilir. Bunlar özellikle sık kullanılan zaman aralıkları için kodu daha okunaklı hale getirir:

@reboot     /usr/local/bin/startup-check.sh   # Sistem her açıldığında bir kez
@yearly     /usr/local/bin/yearly-task.sh     # Yılda bir (0 0 1 1 *)
@annually   /usr/local/bin/yearly-task.sh     # @yearly ile aynı
@monthly    /usr/local/bin/monthly-task.sh    # Ayda bir (0 0 1 * *)
@weekly     /usr/local/bin/weekly-task.sh     # Haftada bir (0 0 * * 0)
@daily      /usr/local/bin/daily-task.sh      # Günde bir (0 0 * * *)
@hourly     /usr/local/bin/hourly-task.sh     # Saatte bir (0 * * * *)

@reboot, sunucu her yeniden başlatıldığında çalıştırılması gereken kontrol scriptleri için oldukça kullanışlıdır — örneğin bir servisin ayakta olup olmadığını doğrulamak veya geçici dizinleri temizlemek gibi.

Sistem Genelindeki Cron Dizinleri

Kullanıcı bazlı crontab'ların yanında, sistem genelinde çalışan görevler için ayrı mekanizmalar vardır:

/etc/crontab — Sistem geneli crontab dosyasıdır. Kullanıcı crontab'larından farkı, komuttan önce hangi kullanıcı ile çalıştırılacağının belirtilmesi gerektiğidir:

# Dakika Saat GünAy Ay HaftaGünü Kullanıcı Komut
0 3 * * * root /usr/local/bin/system-cleanup.sh

/etc/cron.d/ — Paketlerin veya uygulamaların kendi cron tanımlarını bıraktığı dizindir. Her dosya /etc/crontab ile aynı formatı kullanır.

/etc/cron.daily/, /etc/cron.hourly/, /etc/cron.weekly/, /etc/cron.monthly/ — Bu dizinlere script koyduğunuzda, run-parts mekanizması ile ilgili periyotta otomatik çalıştırılırlar. Zaman belirtmenize gerek yoktur, sadece scripti çalıştırılabilir yaparak (chmod +x) doğru dizine bırakmanız yeterlidir.

sudo cp cleanup-tmp.sh /etc/cron.daily/
sudo chmod +x /etc/cron.daily/cleanup-tmp.sh

Erişim kontrolü için /etc/cron.allow ve /etc/cron.deny dosyaları kullanılır. cron.allow dosyası varsa yalnızca içinde listelenen kullanıcılar crontab oluşturabilir; yoksa cron.deny içinde listelenmeyen herkes crontab kullanabilir. Çok kullanıcılı sunucularda kimin zamanlanmış görev oluşturabileceğini sınırlamak istiyorsanız bu dosyaları Linux Kullanıcı ve Grup Yönetimi rehberimizdeki kullanıcı yönetimi pratikleriyle birlikte değerlendirebilirsiniz.

Cron Ortamı, Ortam Değişkenleri ve Sık Karşılaşılan Hatalar

Cron ile ilgili en sık karşılaşılan sorun, "terminalde çalışıyor ama cron'da çalışmıyor" şikayetidir. Bunun temel nedeni, cron'un komutları normal bir login shell ortamından çok daha kısıtlı bir ortamda çalıştırmasıdır. Cron varsayılan olarak sınırlı bir PATH değişkeni kullanır (genelde sadece /usr/bin:/bin), bu yüzden özel dizinlerdeki komutlar veya diliniz için kurduğunuz araçlar bulunamayabilir.

Bu sorunu önlemenin iki yolu vardır:

1. Komutlarda mutlak yol kullanmak:

# Yanlış (PATH'e bağımlı):
0 2 * * * backup.sh

# Doğru (mutlak yol):
0 2 * * * /usr/local/bin/backup.sh

2. Crontab başında gerekli ortam değişkenlerini tanımlamak:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=admin@example.com

0 2 * * * /usr/local/bin/backup.sh

MAILTO değişkeni, çalıştırılan komutun ürettiği standart çıktı veya hata mesajlarını belirtilen adrese e-posta olarak gönderir. Bu, çalışmayan bir görevi hızlıca fark etmenizi sağlayan basit ama etkili bir mekanizmadır. E-posta göndermek istemiyorsanız MAILTO="" şeklinde boş bırakabilirsiniz.

Scriptlerin çalıştırılabilir izinlere sahip olması da sık unutulan bir detaydır. Bir script chmod +x ile işaretlenmemişse cron sessizce başarısız olur. İzin yapısını ve chmod/chown komutlarının nasıl çalıştığını detaylı öğrenmek isterseniz Linux Dosya İzinleri: chmod, chown ve Güvenlik yazımız konuyu baştan sona ele alıyor.

Log Takibi ve Hata Ayıklama

Bir cron görevinin çalışıp çalışmadığını, ne zaman çalıştığını ve hata verip vermediğini takip etmek üretim ortamında kritik önem taşır. Dağıtıma bağlı olarak loglara erişim yöntemi değişir:

# systemd tabanlı dağıtımlarda (journalctl ile)
journalctl -u cron -f
journalctl -u crond -f

# Geleneksel syslog kullanan sistemlerde
tail -f /var/log/cron
tail -f /var/log/syslog | grep CRON

Script çıktısını kendi log dosyanıza yönlendirmek, hata ayıklamayı çok kolaylaştırır:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup-cron.log 2>&1

Burada >> çıktıyı dosyanın sonuna ekler, 2>&1 ise hata çıktısını (stderr) da standart çıktı ile aynı yere yönlendirir. Böylece script başarısız olduğunda hata mesajını kaybetmezsiniz.

Cron loglarının yanı sıra genel sistem log analizi becerileri de sorun tespiti için değerlidir. Cron kaynaklı bir servis kesintisini araştırırken logları etkin biçimde okumak isterseniz Linux Log Yönetimi: Sistem Loglarını Okuma ve Analiz rehberimiz grep, journalctl filtreleme ve log rotasyonu konularını kapsıyor.

Bir görevin cron dışında manuel olarak beklendiği gibi çalışıp çalışmadığını test etmek de iyi bir alışkanlıktır:

# Scripti doğrudan çalıştırarak test edin
sudo -u www-data /usr/local/bin/backup.sh

# Cron servisinin aktif olduğunu doğrulayın
systemctl status cron
systemctl status crond

Gerçek Dünya Senaryoları

Veritabanı yedekleme: Günlük veritabanı dökümünü sıkıştırıp belirli bir dizine kaydeden basit bir örnek:

#!/bin/bash
TARIH=$(date +%Y%m%d)
mysqldump -u dbuser -p'sifre' veritabani | gzip > /backups/db-$TARIH.sql.gz
find /backups -name "db-*.sql.gz" -mtime +14 -delete

0 2 * * * /usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1

Bu örnek hem yedek alır hem de 14 günden eski yedekleri otomatik siler, böylece disk alanı zamanla dolmaz.

SSL sertifika yenileme kontrolü: Let's Encrypt gibi otomatik yenilenen sertifikalarda kontrol scripti genellikle günde iki kez çalıştırılır:

15 3,15 * * * /usr/bin/certbot renew --quiet

Log temizliği: Uzun süre biriken log dosyalarının disk doldurmasını önlemek için:

0 4 * * 0 find /var/log/myapp -name "*.log" -mtime +30 -delete

Disk kullanım uyarısı: Disk doluluğu belirli bir eşiği aştığında bildirim göndermek:

#!/bin/bash
KULLANIM=$(df / | tail -1 | awk '{print $5}' | tr -d '%')
if [ "$KULLANIM" -gt 85 ]; then
  echo "Disk kullanımı %$KULLANIM seviyesinde" | mail -s "Disk Uyarısı" admin@example.com
fi

Bu tür script içerisinde awk ve tr gibi metin işleme araçlarını daha derinlemesine kullanmak isterseniz Linux'ta Metin Dosyası İşleme: grep, sed, awk, cut Komutları yazımız pratik örneklerle konuyu genişletiyor.

Cron ile çalıştırılan scriptlerin çoğu aslında birer bash scriptidir. Sıfırdan otomasyon scripti yazmayı öğrenmek istiyorsanız Bash Script Yazma: Temel Otomasyon Rehberi yazımız değişkenler, koşullar ve döngülerden başlayarak konuyu adım adım anlatıyor.

Büyükweb notu: Kendi sunucunuzda otomatik yedekleme scripti kurmak istediğinizde, disk alanı ve I/O performansı önemli bir kısıtlayıcı olabilir. Yoğun yedekleme veya raporlama işlerini çalıştıracak kaynağa ihtiyaç duyuyorsanız, kaynakları başka kullanıcılarla paylaşmadığınız bir VDS Sunucu ortamı bu tür zamanlanmış işler için daha öngörülebilir performans sunar.

Çakışan Görevleri Önleme: flock ile Kilitleme

Bir cron görevinin çalışma süresi, bir sonraki tetiklenme zamanını aşarsa aynı scriptin iki kopyası aynı anda çalışmaya başlayabilir. Bu durum özellikle veritabanı yedekleme veya senkronizasyon işlerinde veri bütünlüğü sorunlarına yol açabilir. flock komutu bu sorunu basit bir dosya kilidiyle çözer:

* * * * * /usr/bin/flock -n /tmp/backup.lock /usr/local/bin/backup.sh

-n parametresi, kilit zaten alınmışsa (yani önceki çalışma hâlâ sürüyorsa) yeni çalışmayı hemen iptal eder ve script tekrar başlatılmaz. Uzun süren veya süresi öngörülemeyen görevlerde bu satırı eklemek küçük ama önemli bir güvenlik önlemidir.

Görevin arka planda ne kadar süredir çalıştığını veya kaç kopyasının aynı anda ayakta olduğunu kontrol etmek isterseniz ps ve top gibi araçlar işinize yarar. Süreç yönetimini derinlemesine öğrenmek için Linux Süreç Yönetimi: ps, top, kill, systemctl rehberimizi inceleyebilirsiniz.

Cron Güvenliği ve İyi Pratikler

Zamanlanmış görevler sunucunuzda otomatik ve genellikle root yetkisiyle çalıştığı için birkaç güvenlik prensibine dikkat etmek gerekir:

• Root crontab'ını sade tutun. Root yetkisi gerektirmeyen görevleri, ilgili servisin çalıştığı kullanıcı (www-data, mysql vb.) altında tanımlayın.
• Script yollarını ve içeriklerini düzenli denetleyin. /etc/cron.d/ altındaki dosyalar bazen paket kurulumlarıyla sessizce eklenir; bu dizini periyodik gözden geçirmek şaşırtıcı otomatik görevleri fark etmenizi sağlar.
• Scriptlere yalnızca gerekli kullanıcıların yazabilmesini sağlayın. Herkesin yazabildiği bir script dosyası, cron aracılığıyla root yetkisiyle kötü amaçlı kod çalıştırma riski taşır.
• Çıktıları loglayın, sessiz başarısızlığa izin vermeyin. >> log 2>&1 alışkanlığı, "iki hafta önce sessizce bozulmuş" bir yedekleme görevini fark etmenizi sağlar.
• @reboot görevlerini test edin. Sunucu her yeniden başlatıldığında hangi scriptlerin tetiklendiğini bilmek, beklenmedik davranışları önler.

Cron basit görünen ama üretim ortamında istikrarla çalışması gereken bir bileşendir. Zaman söz dizimini doğru kurmak, mutlak yollar kullanmak, çıktıları loglamak ve çakışmaları flock ile önlemek, cron tabanlı otomasyonun sürpriz yapmadan yıllarca sorunsuz çalışmasını sağlar.

Sıkça Sorulan Sorular

Cron görevim crontab -l ile görünüyor ama çalışmıyor, sorun ne olabilir?

En sık neden, script içinde veya crontab satırında göreceli yol kullanılmasıdır. Cron sınırlı bir PATH ile çalışır; komutları ve dosya yollarını mutlak yol (örneğin /usr/local/bin/backup.sh) olarak yazdığınızdan ve scriptin chmod +x ile çalıştırılabilir yapıldığından emin olun.

Crontab'da haftanın günü için hem 0 hem 7 neden Pazar'ı ifade ediyor?

Bu, POSIX cron standardından gelen bir uyumluluk kuralıdır. Bazı sistemler haftayı Pazar (0) ile başlatırken bazı gelenekler Pazar'ı 7 olarak sayar; cron her iki gösterimi de kabul ederek karışıklığı önler.

Kullanıcı crontab'ı ile /etc/crontab arasındaki fark nedir?

Kullanıcı crontab'ı (crontab -e ile düzenlenen) yalnızca o kullanıcının izinleriyle çalışır ve komuttan önce kullanıcı adı belirtilmez. /etc/crontab ise sistem genelindedir ve her satırda hangi kullanıcı ile çalıştırılacağının (örneğin root) açıkça yazılması gerekir.

Cron görevimin çıktısını nasıl e-posta ile alabilirim?

Crontab dosyasının başına MAILTO=eposta@adresiniz.com satırını ekleyin. Görev çalıştığında ürettiği standart çıktı veya hata varsa, sistemde yapılandırılmış bir posta aktarım aracı üzerinden bu adrese iletilir. Posta göndermek istemiyorsanız MAILTO="" yazarak devre dışı bırakabilirsiniz.

@reboot ile tanımlanan görev her açılışta neden bir kez çalışıyor?

@reboot özel ifadesi, cron daemon sistem açılışında ilk kez başlatıldığında bir defaya mahsus tetiklenir. Sunucu yeniden başlatılmadığı sürece tekrar çalışmaz; bu yüzden başlangıç kontrolleri veya tek seferlik temizlik işleri için uygundur.

Aynı script birden fazla kez üst üste çalışıyor, bunu nasıl engellerim?

Script çalışma süresi, cron tetikleme aralığından uzunsa çakışma yaşanabilir. Komutu flock -n /tmp/gorev.lock /yol/script.sh şeklinde sarmalayarak, önceki çalışma bitmeden yenisinin başlamasını engelleyebilirsiniz.

Cron loglarını nereden takip edebilirim?

systemd tabanlı dağıtımlarda journalctl -u cron -f veya journalctl -u crond -f komutlarıyla; geleneksel syslog kullanan sistemlerde /var/log/cron veya /var/log/syslog dosyalarını izleyerek görev geçmişini kontrol edebilirsiniz.

Büyükweb Hizmetleri

• VDS Sunucu — Zamanlanmış görevlerinizi, yedekleme scriptlerinizi ve otomasyon işlerinizi paylaşılmadan, tam kontrolünüzde çalıştırabileceğiniz sanal özel sunucu paketleri.

Cron yapılandırması, sunucu bakımı veya otomasyon süreçlerinizle ilgili sorularınız için 0850 302 60 70 numaralı satış öncesi destek numaramızdan bize ulaşabilir veya iletişim sayfası üzerinden bizimle temasa geçebilirsiniz.