Linux crontab zamanlanmış görevlerini (* * * * *) dakika, saat, gün, ay ve hafta günü olarak görsel seçicilerle oluşturun ve mevcut cron ifadelerinin ne zaman çalışacağını Türkçe okuyun.
Unix ve Linux ekosisteminin en temel zamanlama altyapısı olan Cron, sistem yöneticilerinin ve yazılım geliştiricilerin komut dosyalarını (shell script), konsol komutlarını (PHP CLI, Python, Node.js) ve rutin bakım işlemlerini belirli zaman dilimlerinde veya periyodik aralıklarla arka planda otomatik olarak yürütmesini sağlayan bir zamanlama servisidir (daemon). İlk olarak 1970'li yıllarda Bell Laboratuvarları'nda Unix Version 7 ile ortaya çıkan bu yapı, 1987 yılında Paul Vixie tarafından geliştirilen ve bugün Debian, Ubuntu, CentOS, RHEL, Fedora ve Alpine gibi dağıtımların çekirdeğinde yer alan Vixie Cron implementasyonu ile endüstri standardı (POSIX IEEE Std 1003.1) haline gelmiştir.
Linux işletim sisteminde arka planda kesintisiz çalışan crond (veya cron) servisi, her dakikanın ilk saniyesinde (00. saniye) uyanarak /etc/crontab, /etc/cron.d/ ve kullanıcıya özel /var/spool/cron/crontabs/ dizinlerindeki tabloları stat() sistem çağrısıyla denetler. Dosyaların son değiştirilme zaman damgasında (mtime) veya inode yapısında bir değişiklik varsa tabloları belleğe yeniden yükler; aksi takdirde mevcut zaman damgasıyla eşleşen satırları tespit ederek her bir görev için işletim sistemi düzeyinde yeni bir alt süreç (child process) çatallar (fork + execve).
Linux altyapısında iki farklı düzeyde crontab yapılandırması bulunur:
crontab -e komutu ile düzenlenir ve /var/spool/cron/crontabs/<kullanici> altında izole olarak saklanır. Bu satırlar yalnızca 5 zaman alanı ve yürütülecek komuttan oluşur. Komut, o crontab'ın sahibi olan Linux kullanıcısının yetkileriyle (UID/GID) çalıştırılır./etc/crontab dosyasında ve /etc/cron.d/ altındaki modüler dosyalarda yer alır. Sistem düzeyindeki dosyalarda 5 zaman alanının hemen ardından 6. sütun olarak kullanıcı adı (user) belirtilmesi zorunludur: 0 3 * * * root /usr/local/bin/backup.sh. Kullanıcı alanı atlanırsa crontab komut adını kullanıcı zannederek sözdizimi hatası verir.| Karakter | Tanım & Operatör Mantığı | Örnek İfade | Çalışma Zamanı |
|---|---|---|---|
| * (Joker / Wildcard) | İlgili alanın kapsadığı tüm olası değerleri (dakika için 0-59, saat için 0-23) kabul eder. | * * * * * |
Her dakikanın başında kesintisiz. |
| , (Virgül / Liste) | Aynı alanda virgülle ayrılmış birden fazla ayrık değeri tanımlar. | 15,45 * * * * |
Her saatin 15. ve 45. dakikalarında. |
| - (Tire / Aralık) | İki sınır değer arasındaki tüm ardışık tam sayıları kapsar (kapalı aralık). | 0 9-18 * * 1-5 |
Pazartesi-Cuma arası her gün saat 09:00'dan 18:00'e kadar saat başı. |
| / (Bölü / Adım Değeri) | Belirtilen aralık içinde belirli bir artış sıklığı (step) tanımlar. | */10 * * * * |
0, 10, 20, 30, 40, 50. dakikalarda (her 10 dakikada bir). |
| Kombinasyon (-, /) | Aralık ve adım değerini birleştirerek kısıtlı saat penceresinde sıklık kurar. | 0/15 8-17 * * * |
08:00 - 17:00 saatleri arasında her 15 dakikada bir. |
Sayısal sözdizimini yazmak yerine crontab dosyasında okunabilirliği artırmak için Vixie Cron tarafından sunulan hazır makro takma adları kullanılabilir:
0 0 * * * eşdeğeridir. Her gece yarısı saat tam 00:00'da çalışır.0 * * * * eşdeğeridir. Her saatin ilk dakikasında (00. dakika) çalışır.0 0 * * 0 eşdeğeridir. Her Pazar gecesi saat 00:00'da tetiklenir.0 0 1 * * eşdeğeridir. Her ayın 1. günü gece saat 00:00'da tetiklenir.0 0 1 1 * eşdeğeridir. Her yılın 1 Ocak gecesi 00:00'da bir kez çalışır.Farklı framework ve bulut platformları cron kavramını genişletmiştir. Standart Linux crontab ile modern uygulama zamanlayıcıları arasındaki sözdizimi farklarına dikkat edilmelidir:
? karakteri kullanılır. Linux crontab '?' karakterini desteklemez; syntax error üretir!L (Last = son gün), 15W (15. güne en yakın iş günü), 5#3 (ayın 3. Cuması) gibi operatörler bulunur. Standart Linux cron bu hesaplamaları desteklemez; Linux üzerinde benzer ihtiyaçlar için shell komutunda date veya harici script kontrolleri yapılmalıdır.Modern yazılım mimarilerinde periyodik ve asenkron görevlerin yönetimi için kullanılan 4 temel yaklaşımın teknik yetenekleri ve mimari sınırları:
| Teknoloji / Mimari | Zaman Çözünürlüğü | Durum Takibi & Kuyruk | Çakışma Önleme (Locking) | Hata Yeniden Deneme (Retry) | İdeal Kullanım Alanı |
|---|---|---|---|---|---|
| Linux Crontab (Vixie) | 1 Dakika (60 sn) | Yok (Stateless) | Manuel (flock gerekir) | Yok (Exit code sadece) | Sunucu bakım scriptleri, log rotasyonu, basit yedeklemeler. |
| Systemd Timers (.timer) | 1 Milisaniye / Saniye | Var (Systemd State) | Yerleşik (RefuseManual) | Persistent=true (Kaçırılanı yapar) | Cgroups ile RAM/CPU limitli görevler, modern Linux servisleri. |
| Dağıtık Kuyruklar (Celery, BullMQ) | Milisaniye (Event-driven) | Gelişmiş (Redis/RabbitMQ) | Dağıtık Mutex (Redlock) | Exponential Backoff / DLQ | E-ticaret sipariş işleme, toplu SMS/e-posta gönderimi, webhooks. |
| Cloud Scheduler (AWS / GCP) | 1 Dakika | Tam Yönetilen (CloudWatch) | Altyapı Düzeyinde | Otomatik Retry & DLQ Entegre | Serverless Lambda fonksiyonları, Cloud Run, çok bölgeli mimariler. |
Senaryo & Problem: 85.000 aktif ürün stoğuna sahip bir e-ticaret sitesi, ERP API'sinden güncel stok ve fiyat verilerini çekmek için her dakikada bir çalışan bir PHP CLI cron görevi tanımlamıştır: * * * * * /usr/bin/php /var/www/artisan stock:sync. Cuma günü kampanya esnasında ERP sunucusu aşırı yük nedeniyle yavaşlamış ve normalde 20 saniye süren senkronizasyon işlemi 85 saniyeye uzamıştır. Standart cron bir önceki görevin bitip bitmediğini denetlemediği için her dakikanın başında yeni bir PHP süreci başlatmıştır. 5 dakika içinde sunucuda eşzamanlı çalışan 6 adet stok güncelleme süreci oluşmuş; MySQL veritabanında Lock wait timeout exceeded ve deadlock patlaması yaşanmış, sunucu CPU kullanımı %100'e fırlamış ve ana web sitesi kullanıcılara 504 Gateway Timeout hatası vermeye başlamıştır.
Uygulanan Çözüm: Linux util-linux paketinin sağladığı flock dosya kilitleme mekanizması devreye alınmıştır. Kilitleme bayrağı -n (non-blocking) olarak ayarlanarak, bir önceki görev hala devam ediyorsa yeni dakikadaki sürecin beklemeden ve hata fırlatmadan sessizce sonlanması sağlanmıştır:
Teknik Sonuç: ERP API'si gecikse dahi sunucuda aynı anda yalnızca tek bir senkronizasyon süreci çalışabilmektedir. Çakışma girişimi olduğunda flock kilit dosyasını kontrol etmiş, yeni görevi 0 milisaniyede sonlandırarak CPU ve RAM tüketimini sıfırda tutmuştur. Deadlock oluşumu tamamen engellenmiş ve web sitesi kesintisiz hizmet vermeye devam etmiştir.
Senaryo & Problem: 60 GB boyutunda işlem geçmişi barındıran bir SaaS veritabanı her gece saat 02:30'da yedeklenmektedir. Başlangıçta yazılan basit cron komutu (30 2 * * * mysqldump -u root db > /backup/db.sql), dump esnasında sunucunun disk I/O kapasitesini tüketmiş ve gece saatlerinde çalışan faturalandırma işlemlerini durma noktasına getirmiştir. Daha da kötüsü, sunucu diski dolduğunda dump işlemi yarım kalmış fakat exit code denetlenmediği için yönetim ekibi yedeğin alındığını varsaymıştır.
Uygulanan Çözüm: Veritabanı yedeği, diskte yer kaplamadan doğrudan boru hattı (pipeline) ile RAM üzerinden sıkıştırılarak AWS S3 bulut depolamaya aktarılmış; CPU ve Disk I/O önceliği nice ve ionice araçlarıyla minimum seviyeye çekilmiştir. Ayrıca mantıksal || operatörüyle komut başarısız olduğunda anında Slack DevOps kanalına webhook bildirimi gönderen bir akış kurulmuştur:
Teknik Sonuç: ionice -c 3 (Idle class) sayesinde yedekleme işlemi canlı veritabanı trafiğine hiçbir I/O yükü getirmemiştir. S3'e doğrudan aktarım yerel diskte 60 GB boş alan tutma zorunluluğunu ortadan kaldırmış; olası bir network kesintisi veya dump hatasında nöbetçi mühendislere 5 saniye içinde Slack uyarısı iletilmesi sağlanmıştır.
| Hata Tipi | Görülen Semptom & Risk | Yanlış Kullanım | Doğru & Güvenli Yaklaşım |
|---|---|---|---|
| 1. PATH Eksikliği | Terminalde çalışan komut cron'da "command not found" hatası verir. | 0 * * * * php artisan test |
0 * * * * /usr/bin/php /var/www/artisan test |
| 2. Lock Mekanizmasızlık | Geciken görevler üst üste biner, CPU %100 olur ve veritabanı kilitlenir. | * * * * * python sync.py |
* * * * * flock -n /tmp/sync.lck python sync.py |
| 3. Çıktı / Log Başıboşluğu | Sunucuda MTA yoksa çıktılar yok olur; varsa /var/spool/mail şişerek diski doldurur. | 0 0 * * * /backup.sh |
0 0 * * * /backup.sh >> /var/log/b.log 2>&1 |
| 4. DOM & DOW OR Mantığı | Hem ay günü hem hafta günü girildiğinde AND değil OR çalışır; görev beklenenden sık tetiklenir. | 0 0 15 * 1 (15'i Pazartesi zannedilir) |
0 0 15 * * [ $(date +\%u) -eq 1 ] && komut |
| 5. Timezone & DST İhmali | Sunucu UTC çalışırken yerel saate göre planlanan görevler 3 saat erken veya geç başlar. | 0 9 * * * (Sunucu UTC iken TR 12:00'ye denk gelir) |
Crontab başına CRON_TZ=Europe/Istanbul ekleyin. |
| 6. % Karakteri Kaçışsızlığı | Cron `%` işaretini yeni satır (newline) sayar; `date +%Y` komutları sessizce kırılır. | 0 0 * * * tar -czf backup-$(date +%F).tar.gz |
0 0 * * * tar -czf backup-$(date +\%F).tar.gz |
Inovoice olarak kurumsal Linux sunucu optimizasyonu, otomatik yedekleme sistemleri, Redis/RabbitMQ asenkron kuyruk mimarileri ve 7/24 kesintisiz yüksek erişilebilirlik (HA) çözümleri sunuyoruz.