Cron çalışmıyor mu? Sunucuda kontrol listesi (net adımlar)

Cron (zamanlanmış görev) çalışmıyorsa çoğu zaman sorun uygulamada değil, sunucu tarafındaki birkaç kritik noktada olur. Bu rehberde, “Cron çalışmıyor” durumunda ilk 30 dakikada hangi loglara bakacağınızı, hangi servisleri doğrulayacağınızı ve hangi ayarların en sık hataya yol açtığını net bir kontrol listesiyle öğreneceksiniz. Ayrıca WordPress/uygulama kökenli gecikmeler ile gerçek cron arızasını birbirinden ayıracak ölçümleri de göreceksiniz.

1) Cron gerçekten çalışıyor mu? Servis ve durum doğrulama

Önce cron’un süreç olarak ayağa kalktığını doğrulayın. VDS/VPS/dedicated sunucularda cron, distro’ya göre farklı servis adıyla çalışır.

Linux’ta cron servisini kontrol edin

Aşağıdaki komutlar sisteminizde cron’un aktif olup olmadığını gösterir:

• Debian/Ubuntu:
• systemctl status cron
• CentOS/RHEL:
• systemctl status crond

Aktif değilse şu adımla toparlayın: - Servisi yeniden başlatın: systemctl restart cron veya systemctl restart crond - Sonra tekrar durum kontrol edin.

Kron job’un “kuyruğa düşmesini” engelleyen yaygın durumlar

• Sistem saatinin (system clock) çok geride/ileri olması
• Disk doluluğu (loglar ve spool dosyaları şişebilir)
• Cron’un kullandığı spool klasörünün (genelde /var/spool/cron/*) yetkisizliği ya da bozulması

Hızlı kontrol: - Disk doluluk: df -h - En son cron denemelerinin olduğu loglar: bir sonraki başlıkta.

2) Hata nerede? Loglar üzerinden “olay kaynağını” bulun

Cron sorunlarında en hızlı yol, loglarda gerçekten “ne denendiğini” görmek ve hatayı bulmaktır. Sisteminizde farklı dosya isimleri olabilir; ama mantık değişmez: cron, çalışmayı denedi mi ve script çıktısında hata var mı?

En sık kullanılan cron log konumları

Dağıtıma göre şunlardan biri görünür: - /var/log/cron - /var/log/syslog (Ubuntu/Debian’da cron satırları burada da olabilir) - /var/log/messages (bazı sistemlerde)

Örnek yaklaşım (tarih aralığına göre): - Son 100 satır: tail -n 200 /var/log/cron - Syslog içinden cron filtre: grep CRON /var/log/syslog | tail -n 200

Eğer “hiç cron satırı yok” ise iki ihtimal öne çıkar: 1) Cron servisi hiç çalışmıyor (1. başlık) 2) Log yazımı kapalı/rotasyonla yer değiştirmiş ya da doğru dosya takip edilmiyor

Mail/terminal çıktısı varsa logu beklemeyin

Bazı kurulumlarda cron’un çıktısı e-posta ile gider. Sunucunuzda mail transfer agent (Postfix vb.) düzgünse “job çıktısı” posta kutusuna düşebilir. Loglarda sadece “çalıştırıldı” görüp komutun kendisinde hata mesajını görmemenizin sebebi bu olabilir.

Kontrol: - Cron satırında komut sonunda >> /path/to/log 2>&1 ekli misiniz? - Yoksa çıktı mail olarak mı gidiyor?

Net öneri: Şüpheli dönem için her job’a kısa süreli dosya loglama ekleyin.

3) Cron satırının kendisi neden atlanıyor? Sözdizimi ve zaman dilimi

Cron’un çalışmamasının en sık nedeni “sözdizimin düzgün olmaması” değil, çoğunlukla doğru girildiği halde çalışma zamanının beklendiği gibi olmamasıdır. Bunun arkasında zaman dilimi (timezone) farkları, eksik alanlar veya ortam değişkeni farkları bulunur.

Cron zaman alanlarını doğrulayın

Standart cron (5 alan): - dakika saat ayın_günü ay ayar (örnek: */5 * * * *)

Net kontrol: - Satırda sayıların yerleri kaymış mı? - Gün adı (ör. MON-FRI) gibi ek formatlar kullanıyorsanız destek var mı?

Zaman dilimi (timezone) kontrolü

Sunucu saati beklediğiniz bölgeyle aynı değilse job “hata varmış gibi” görünür. - Zaman dilimi: timedatectl - Saat: date

Beklenen şey: Uygulama sunucunun saatine göre rapor veriyorsa cron’da da aynı timezone üzerinden hesap yapılmalıdır.

Uygulama/Script “o anki dizini” bekliyor olabilir

Cron komutu, interaktif shell gibi bir çalışma diziniyle gelmez. Örneğin script “./config” arıyor ama cron /root gibi farklı bir dizinde çalıştırıyorsa dosya bulunmaz.

Net kontrol: - Cron’da script yolu mutlak mı? (örnek: /var/www/site/scripts/job.sh) - Çalışma dizini gerekiyorsa: komutun başında cd /var/www/site && ...

4) Yetki ve PATH farkları: Cron’un environment’ı interaktif değildir

Cron, genelde sizin terminalde yaptığınız gibi aynı environment değişkenleriyle çalışmaz. Bu yüzden “komut çalışıyor ama cron’da çalışmıyor” problemi çok yaygındır.

En sık sorun: PATH değişkeni

Örnek senaryo: Terminalinizde php komutu çalışır ama cron satırında php bulunamadığı için job sessizce düşer.

Net çözüm: - Komutları mutlak yoldan çağırın. - php yerine /usr/bin/php - Veya cron’a PATH tanımlayın (duruma göre).

Örnek net yaklaşım: - Cron komut satırı: /usr/bin/php /var/www/site/artisan schedule:run

Yetkiler: script çalıştırma izni

• Script dosyası yürütülebilir mi? chmod +x /path/to/script.sh
• Cron’un çalıştığı kullanıcı (örnek www-data, root, ubuntu) scripti okuyabiliyor mu?
• Dosya/soket/erişim izinleri (özellikle /var/www/* ve log dizini) doğru mu?

Net kontrol: - Cron job’un hangi kullanıcıyla çalıştığını cron girdisinden veya kontrol panelinden doğrulayın.

Dosya yolu ve log yolu da yetki ister

Log dosyasına yazamıyorsa job hata alır ya da hatayı loglayamaz. - Cron komutunda >> /var/log/xyz.log 2>&1 kullanıyorsanız hedef dizin yazılabilir olmalı.

5) “Gerçekte cron değil başka şey” mi? Uygulama gecikmesi, kilit (lock) ve çakışma

Bazen cron job çalışır; ama script içinde kilit (lock) veya zamanlayıcı çakışması yüzünden “iş yapılmıyor” gibi görünür. Özellikle WordPress, Laravel scheduler, yoğun işler, dış API çağrıları ve queue kullanan sistemlerde bu durum sık görülür.

Çakışmayı engelleyen kilit mekanizması var mı?

Örnekler: - Script, daha önce çalışmış bir PID/lock dosyası varsa yeni çalışmayı iptal eder - Önbellek/lock tablosu dolmuştur

Net kontrol: - Job’un kaynak kodunda lock/flag araması var mı? - Uygulamanın kullandığı “lock” dosyası veya tablo temizlenmeden kalıyor mu?

Uygulama loglarını cron zamanıyla birlikte okuyun

Cron logu “çalıştırıldı” diyebilir ama uygulama hata verebilir. - Laravel: storage/logs/laravel.log - Node: process logları - WordPress: wp-content/debug.log (debug açılırsa)

Net yaklaşım: - Cron job’un tetiklendiği dakikayı bulun - Aynı zaman aralığında uygulama logunda hata var mı bakın

Script çok uzun sürüyorsa: timeout ve kaynak kısıtları

Cron işinin zamanında bitmemesi, sonraki çalışmaları geciktirebilir veya sistem kaynakları tükenince job düşebilir. - CPU/RAM doluluk kontrolü: top/htop - OOM (Out of memory) izleri: dmesg | grep -i oom

Bu tarz sistemik sorunda cron “çalışıyor” ama işi yapamıyor görünür.

6) Kontrol paneli vs sistem cron’u: Aynı anda iki yer kontrol edin

VDS/VPS tarafında iki farklı cron yönetimi görebilirsiniz: - Sunucu sistemi cron’u (crontab) - Hosting kontrol paneli cron’u (cPanel, Plesk vb.)

Tek tek doğrulama yöntemi

1) Sistem cron dosyalarına bakın: - crontab -l (mevcut kullanıcı için) 2) Diğer kullanıcıların crontab’ı olabilir: - root için ayrı crontab varsa sudo crontab -l 3) Kontrol panelinden cron job gerçekten ekli mi ve doğru kullanıcıyla mı çalışıyor kontrol edin.

Panel cron’unda PATH ve kullanıcı farkı sık olur

Panel, komutu farklı bir kullanıcı/çalışma diziniyle tetikleyebilir. “Terminalde çalışıyor, panel cron’da çalışmıyor” durumunun kökü genellikle environment farklılığıdır.

Net çözüm aynı kalır: - Komutlarda mutlak yol kullanın - cd ile çalışma dizinini sabitleyin - Çıktıyı loga yönlendirin

7) Hızlı teşhis için 15 dakikalık net test planı

Sorunu hızla sınıflandırmak için şu sırayı izleyin:

Test 1: Cron tetikleniyor mu?

Geçici bir job ekleyin (örnek her dakika): - Komut: her tetiklenmede loga tek satır yazsın - Örnek komut mantığı: date çıktısını bir log dosyasına append edin

Job tetikleniyorsa cron zamanlaması doğru. Tetiklenmiyorsa: - 1. başlık (servis) - 2. başlık (log)

Test 2: Komut environment’ı

Test job’da terminaldeki komutun aynısını kullanmayın; mutlak path ile çağırın. - php veya python için tam yol - script için mutlak dosya yolu

Test 3: Yetki ve çalışma dizini

Test job içinde pwd ve hedef dosya yazma kontrolü ekleyin. - Çalışma dizini beklendi mi? - Log dosyasına yazabiliyor mu?

Test 4: Uygulama/iş katmanı

Cron tetikleniyor ve ortam doğru ama asıl iş yapılmıyorsa uygulama tarafına geçin: - Uygulama loglarında hata var mı? - Kilit/lock çakışması var mı?

Sonuç: Aksiyon planı

Cron çalışmıyor sorununda ilk aksiyon, cron servisini doğrulamak ve doğru log dosyalarında “tetikleme denemesi” olup olmadığını görmek olmalıdır. Ardından cron satırının zamanlamasını (timezone ve sözdizimi), cron’un environment/izin farklarını (PATH, mutlak yol, çalışma dizini) ve uygulama kaynaklı kilit/timeout etkilerini sırayla kontrol edin. Bu kontrol adımlarını uygulayın; cron’un mu yoksa job’un içindeki uygulamanın mı sorun olduğuna net biçimde karar verin.