Cron çalışmıyor: Sunucuda kontrol edilecek 15 kritik nokta

Cron job’ların çalışmaması, özellikle otomatik yedek (backup), raporlama, e-posta gönderimi ve web uygulaması görevlerinde doğrudan arıza yaratır. Sorun çoğu zaman “cron yok”tan değil; ama zamanlama, servis durumu, komut yolu, izinler, shell farkları ve environment değişkenleri gibi noktalardan kaynaklanır. Bu rehberde, cron çalışmıyor durumunda sunucuda sırasıyla hangi alanları kontrol etmeniz gerektiğini net bir kontrol listesiyle anlatıyorum.

Aşağıdaki adımlar Linux (özellikle Debian/Ubuntu/CentOS/RHEL) VDS/VPS/dedicated sunucularda geçerlidir. cPanel/Plesk gibi kontrol panelleri de kullanıyorsanız, yine aynı mantık geçerlidir: önce cron mekanizmasının kendisi, sonra job’un komutu ve çalıştığı ortam doğrulanır.

1) Önce cron motoru çalışıyor mu? (crond / cron)

Cron job’ların tetiklenmesi için sistem cron servisi (daemon) aktif olmalıdır. En sık hata: servis durması ya da farklı isimle çalışması.

Ubuntu/Debian

• Servisin durumu:
• systemctl status cron
• Servisi başlatma:
• sudo systemctl start cron
• Otomatik açılış:
• sudo systemctl enable cron

CentOS/RHEL

• Durum kontrol:
• systemctl status crond
• Başlatma:
• sudo systemctl start crond
• Otomatik açılış:
• sudo systemctl enable crond

Net kontrol: Servis active (running) değilse, job’ların loga düşmesini beklemeyin.

2) Cron logları nerede ve ne görüyor? (en hızlı doğrulama)

Cron sorununun en pratik yolu: log’ları doğrudan incelemek. Dağıtıma göre log yolu değişir.

Yaygın log kaynakları

• Debian/Ubuntu: /var/log/syslog içinde cron satırları
• grep CRON /var/log/syslog
• RHEL/CentOS: /var/log/cron
• cat /var/log/cron
• Daha yeni sistemlerde journalctl
• journalctl -u cron --since "-1 hour"
• journalctl -u crond --since "-1 hour"

Log okuma ipuçları

• Job hiç tetiklenmiyor: Logta ilgili satır görünmez.
• Tetikleniyor ama komut başarısız: Logda exit kodu veya hata mesajı olur.

3) Job tanımı doğru mu? (kron satırı, kullanıcı, saat)

Cron satırını hatalı oluşturmak en yaygın ikinci nedendir.

Doğrulamanız gereken alanlar

• Job hangi kullanıcı altında tanımlı?
• Sistem crontab’larında kullanıcı alanı önemlidir.
• Sıklık (dakika/saat/gün/ay/hafta günü) doğru mu?
• Komut tam olarak doğru mu? (tırnaklar, boşluklar, redirect >>)

Kullanım farkı: crontab -e vs sistem cron

• crontab -e ile düzenlediğiniz job’lar, mevcut kullanıcı altında çalışır.
• /etc/crontab ve /etc/cron.d/* içindeki job’lar genelde kullanıcı alanı ister.

Net kontrol: Job’ı yanlış kullanıcıya tanımladıysanız, beklediğiniz PATH/izinler ve çalışacak dosya yerleri uyuşmaz.

4) Komut “terminalde çalışıyor” ama cron’da mı patlıyor? PATH farkı

Cron, komutu genellikle sınırlı bir environment ile çalıştırır. Terminalde çalışması; cron’da aynı komutun çalışacağı anlamına gelmez.

PATH kaynaklı tipik sorun

• Komutun tam yolu kullanılmıyor.
• Cron PATH’i, sizin alışık olduğunuz dizinleri içermiyor.

Çözüm yaklaşımı

1) Komutu mutlak path ile çağırın: - Örn: */5 * * * * /usr/bin/php /var/www/app/artisan schedule:run 2) Gerekirse job içine PATH tanımlayın: - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

5) Shell farkı: /bin/sh mi bash mi?

Cron çoğu zaman /bin/sh kullanır. Komutlarınız bash-özellikliyse (ör. [[ ... ]], bazı array kullanımları), cron’da farklı sonuç doğar.

Net kontrol

• Job’un içinde script çağırıyorsanız script’in başına doğru shebang ekleyin:
• #!/bin/bash

• veya gerekiyorsa #!/usr/bin/env bash

• Cron satırında doğrudan bash ile çalıştırın:

• * * * * * /bin/bash /path/to/script.sh

6) Dosya izinleri ve sahipliği: “çalıştırma hakkı” şart

Cron job’lar, komut dosyanızı okuyabilmeli ve çalıştırabilmelidir.

Kontrol edin

• Script çalışıyor mu?
• ls -l /path/to/script.sh
• Çalıştırma izni var mı?
• chmod +x /path/to/script.sh
• Job’un çalıştığı kullanıcı, dosyaları okuyabiliyor mu?
• stat ile izin/owner kontrolü

Net kontrol: Script “manuel çalışıyor” olabilir ama cron başka kullanıcıyla çalışıyorsa yine yetki hatası verir.

7) İşin dizini (working directory) farklı: relative path tuzağı

Cron genellikle job’u kullanıcı home dizininden veya cron’un varsayılan çalışma dizininden çalıştırır. Bu yüzden ./config gibi relative path’ler cron’da bulunamayabilir.

Çözüm

• Script içinde cd ile dizini sabitleyin:
• cd /var/www/app && ...
• Ya da script içinden her yolu mutlak verin.

8) Environment değişkenleri: DB şifresi, API key, .env

Uygulama görevlerinde en sık sorun: cron job “uygulama environment’u” olmadan çalışıyor.

Net kontrol

• Uygulamanın kullandığı config .env dosyası cron’da yükleniyor mu?
• Job tanımında gerekli değişkenler var mı?

Pratik çözüm örneği

• Eğer .env kullanıyorsanız (Node/PHP/laravel fark etmez), job içinde gerekli export’ları yapın ya da uygulama tarafında .env yüklenmesini standardize edin.
• Mantık: cron, interaktif shell’deki otomatik export’ları otomatik almaz.

9) Zamanlama ve timezone hatası: UTC vs yerel saat

Cron çalışsa bile “beklediğiniz saatte” çalışmıyor gibi görünebilir.

Kontrol

• Sunucunun timezone’u:
• timedatectl
• Cron’un kullandığı sistem saati doğru mu?

Net çözüm

• Cron satırlarını yazarken timezone’u netleştirin.
• Uygulama saatini başka bir timezone’da kullanıyorsanız, rapor saatleri kayabilir.

10) Cron e-postası/çıktı: Hata mesajını yakalayın

Cron’da standart çıktı ve hata genellikle e-posta olarak gidebilir veya hiç görünmeyebilir. Görünür hale getirmek teşhisi hızlandırır.

Net kontrol: redirect kullanın

• Örn:
• */5 * * * * /path/to/script.sh >> /var/log/myjob.log 2>&1

Bu sayede cron tetiklendi mi ve neden başarısız oldu mu doğrudan görürsünüz.

11) “Job çalışıyor ama bitmiyor” senaryosu (kilit/lock)

Uzun süren job’lar çakışma yaratır; bazı sistemlerde lock mekanizması yoksa ikinci tetiklenme ilkini bekler veya çakışır.

Net kontrol listesi

• Script sonunda doğru exit code dönüyor mu?
• Paralel koşul var mı? (örn. aynı dosyaya yazma)
• Uygulama tarafında file lock / process lock var mı?

Tipik çözüm

• Job başında bir lock dosyası oluşturup sonunda kaldırın.
• Uygulama tarafında “single instance” kontrolü kullanın.

12) Sistem kısıtları: cron service erişimi, SELinux/AppArmor

Bazı ortamlarda (özellikle SELinux) cron job dosyalara erişemeyebilir.

Net kontrol

• SELinux açık mı?
• getenforce
• Uygulama loglarında denial (reddetme) var mı?
• journalctl veya audit logları

Çözüm yaklaşımı

• İzinler + bağlam (context) doğru olmalı.
• SELinux audit çıktısı, hangi dosya/işlem engellendiğini gösterir.

13) Control panel kullanıyorsanız: cron “hosting paneli” tarafında mı?

cPanel/Plesk gibi panellerde cron oluşturma, bazen panelin kendi mekanizmasıyla ilerler. Yine de sistem servisleriyle bağlantı vardır.

Net kontrol

• Panelde oluşturduğunuz job etkin mi?
• Komut kısmında PATH/relative path sorunu var mı?
• Panelin log ekranı veya sistem loglarına düşen kayıt var mı?

Net kontrol: Panelde “enabled” görünüp sistem loglarında hiçbir şey yoksa, panelin cron’u yazdığı dosyanın gerçekten okunduğunu doğrulayın.

14) Eklentiler/ör. logrotate veya yedek scriptleri ile çakışma

Cron ile çalışan görevler birbirini etkileyebilir. Özellikle log dosyalarını döndürme (logrotate), yedekleme ve disk temizliği aynı zamanlara denk gelirse.

Net kontrol

• Aynı dakikalarda birden fazla job var mı?
• Job’lar aynı dizine yazıyor mu?
• Disk doluluğu (disk full) var mı?
• df -h

15) Hızlı “teşhis” testi: cron’un çalıştığını 1 dakikada kanıtlayın

Kök nedeni bulmadan önce “cron tetikleniyor mu?” kanıtı alın.

Örnek test job

• * * * * * date >> /tmp/cron_test.log 2>&1

1 dakika sonra dosyada yeni satır var mı? - Var: Cron tetikleniyor, asıl sorun job komutunda/environment’ta. - Yok: Servis/izin/tanım/timezone sorunu.

Net teşhis tablosu: Belirtiye göre yönlendirme

Sonuç: Bir aksiyon planı ile dakikalar içinde kök nedeni bulun

Cron’un çalışmaması durumunda hedefiniz, önce cron motorunun tetikleme yaptığına (servis + log + test job), sonra job’un çalıştığı ortamın (PATH, shell, çalışma dizini, izinler, environment) doğru olduğuna emin olmaktır. İlk 10 dakikada yapmanız gereken net sıralama: (1) cron servisi active mi, (2) loglarda cron satırı var mı, (3) 1 dakikalık test job yazıp tetiklenmeyi kanıtla, (4) job komutunu mutlak path ve doğru shell ile yeniden düzenle, (5) stdout/stderr’ı loga yönlendirip hatayı görünür hale getir.

Bu adımları uyguladığınızda, sorun %90 oranında “yanlış ortam / yanlış yol / izin veya timezone” ekseninde net şekilde görünür. Sorun devam ederse, log satırlarını (cron tetikleniyor mu, hata ne) paylaşmadan ilerlemeyin; çünkü doğru veri olmadan tahmin yapmak süre kaybettirir.