Cron çalışmıyor: Sunucuda kontrol listesi (Linux)

Cron (zamanlanmış görev) çalışmıyorsa sorun çoğu zaman “cron bozuldu” değildir. Sorun; görev tanımındaki küçük bir ayrıntı, zaman dilimi (timezone), PATH/env değişkeni, eksik izinler ya da cron loglarının sessiz kalması gibi nedenlerden çıkar. Bu rehberde, Cron’un neden çalışmadığını sırayla doğrulayacak net bir kontrol akışı öğreneceksiniz. Ayrıca NetKıyas’ta karşılaştırılan VDS/VPS senaryolarında sık görülen uygulama bağımlılıklarını (node/php script yolu, yorumlayıcı, servis yeniden başlatma) kontrol etmeyi de öğreneceksiniz.

1) Önce hangi cron türü çalışıyor: user cron mu, sistem cron mu?

Linux’ta cron mantığı dağıtıma göre değişir ama genelde iki ana katman vardır: - User crontab: Her kullanıcı için ayrı zamanlanmış işler (örn. crontab -e ile düzenlenenler) - System cron: Paketle gelen cron daemon’u ve sistem servisleri (çoğunlukla cron, bazı sistemlerde crond)

Hızlı teşhis: cron daemon çalışıyor mu?

Aşağıdaki komutlar cron servisinin gerçekten çalıştığını gösterir: - systemctl status cron - veya bazı dağıtımlarda: systemctl status crond

Servis çalışmıyorsa cron hiç tetiklenmez. Bu durumda yapılacaklar: - systemctl enable --now cron (veya crond) - Ardından loglara bakın (aşağıda).

Kullanıcı crontab’ını doğru kullanıcıyla mı düzenlediniz?

Cron girdisini eklediğiniz kullanıcı ile çalıştırmanız gereken komutun çıktısı aynı kullanıcıya ait olmalıdır. Örneğin root adına eklenmiş ama beklenen görev başka kullanıcıdan bekleniyorsa çalışsa bile “siz görmüyor olabilirsiniz”.

Kontrol: - Mevcut crontab’ı görmek için: crontab -l - Başka bir kullanıcı için: sudo crontab -l -u <kullanici>

2) Loglarda “tetiklendi mi, tetiklenmedi mi?” sorusunu netleştirin

Cron’un çalışmamasında en kritik adım, loglardan ne kadar bilgi alabildiğinizi doğrulamaktır. Dağıtımın log konfigürasyonuna göre log dosyası değişir.

En yaygın loglar

• Debian/Ubuntu benzeri: /var/log/syslog içinde cron kayıtları
• RHEL/CentOS/Alma/Rocky: /var/log/cron veya /var/log/cronicle benzeri

Kontrol örnekleri: - grep CRON /var/log/syslog | tail -n 200 - grep CRON /var/log/cron | tail -n 200

Hedef: Cron daemon’un “job started” gibi bir kayıt üretip üretmediğini anlamak.

Journalctl ile tek noktadan kontrol

Systemd kullanan sistemlerde şu komut da işe yarar: - journalctl -u cron -S today --no-pager - veya journalctl -u crond -S today --no-pager

Burada görmeniz gerekenler: - Job tetikleniyor mu? - Hata var mı? (ör. “command not found”, “permission denied”, “/bin/sh: …”)

3) Zaman dilimi (timezone) ve “takvim tutmuyor” senaryosu

Cron ayarı doğru görünse bile saat farklı olabilir. Özellikle sunucu VPS/VDS’lerde çoğu zaman panel/OS timezone farkı görülür.

Sunucu timezone’unu kontrol edin

• timedatectl

Önemli alanlar: - Time zone - System clock set

Cron satırında beklediğiniz dakika/saat mi yazıyor?

Cron formatı şu şekildedir: * * * * * komut - Sırasıyla dakika, saat, ayın günü, ay, haftanın günü.

Net kontrol için örnek: - */5 * * * * /usr/bin/php /var/www/app/script.php : her 5 dakikada bir.

Eğer beklediğiniz saat 03:00 iken sunucu 06:00 gösteriyorsa bu komut 3 saat kayar.

4) PATH ve ortam değişkenleri: “Çalışıyor ama cron’da çalışmıyor”ın ana sebebi

Cron, etkileşimli shell’inize göre çok daha kısıtlı bir ortamla çalışır. Sen terminalde çalıştırdığında PATH’in içinde olan komut cron’da bulunamayabilir.

Belirti

• Loglarda /bin/sh: 1: komut: not found benzeri hatalar

Çözüm: Komutları tam yol ile çağırın

Örnek: - Yanlış: python script.py - Doğru: /usr/bin/python3 /var/www/app/script.py

PATH’i cron içinde tanımlayın (net ve kontrollü)

Crontab başına şu satırları eklemek çok net sonuç verir: - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Alternatif yaklaşım: sadece komutları tam yol ile çağırmak (daha deterministik).

5) Yorumlayıcı (PHP/Node/Python) ve shebang uyuşmazlığı

Özellikle scriptlerin uzaktan çalıştırılmasında cron şunları yapar: - Dosyayı shell ile değil, belirtilen komutla çalıştırır. - Shebang (#!/usr/bin/env node gibi) doğru değilse tetiklenmez.

PHP örneği

• Yanlış: php /var/www/app/artisan schedule:run
• Doğru: /usr/bin/php /var/www/app/artisan schedule:run

Node örneği

• Yanlış: node server.js
• Doğru: /usr/bin/node /var/www/app/server.js

Dosya izinleri

Script dosyası çalıştırma iznine sahip değilse hata verir. Kontrol: - ls -l /path/to/script - Gerekirse: chmod +x /path/to/script

6) Kullanıcı izinleri, dosya sahipliği ve çalışma dizini (working directory)

Cron komutu genellikle crontab satırında verilen komut ve mevcut çalışma dizini üzerinden gider. Görevin dosya yolu göreli (relative) ise cron farklı dizinde başlayıp dosya bulamaz.

Net çözüm: Mutlak dizin kullanın

• Göreli yol yerine: /var/www/app/storage/logs/...

Working directory’yi sabitleyin

Cron içine cd ekleyin: - * * * * * cd /var/www/app && /usr/bin/php artisan command:run >> /var/log/app/cron.log 2>&1

Bu yaklaşım hataların kaydını da netleştirir.

Çalıştıran kullanıcı dosyaları okuyabiliyor mu?

Kontrol: - sudo -u <kullanici> ls -l /var/www/app - Log dosyasına yazabiliyor mu?

7) Çıktıyı yakalayın: sessiz başarısızlıklar

Cron satırı doğru olsa bile hata oluşur ve siz görmezsiniz. Bu yüzden çıktıyı mutlaka dosyaya yönlendirin.

Hata ayıklama için standart redirect

Örnek: - 0 * * * * /usr/bin/python3 /opt/job/run.py >> /var/log/job/cron.log 2>&1

Bu sayede loglarda şunları görürsünüz: - Stack trace - permission denied - bağlantı hataları

Mail ile bildirim (varsa) yerine log tercih edin

Cron mail gönderimi bazı sistemlerde düzgün ayarlanmaz. En hızlı teşhis için dosya redirect’i kullanın.

8) “Komut çalıştı ama beklenen sonuç oluşmadı” senaryosu

Cron tetikleniyor, log var ama iş “işlem yapmıyor” olabilir. Bu durumda genelde şunlar vardır: - Script doğru ama dış bağımlılık yok: veritabanı erişimi, API anahtarı, çevresel değişkenler (env) - Zamanlanmış görev “lock” mekanizması yüzünden atlıyor - Sistem kaynakları yetersiz (CPU/RAM) ve görev zaman aşımına uğruyor

Ortam değişkenlerini kontrol edin (env/secret)

Cron’da terminalde export ettiğiniz değişkenler yoktur. Bu yüzden uygulama config’i doğrudan env dosyasına bağlıysa cron’da eksik kalır. Net çözüm seçenekleri: - Her gereken değişkeni crontab içine eklemek - Uygulama tarafında env okuyan mekanizmayı doğru kurmak

DB bağlantısı ve erişim

Örnek net test: - Cron kullanıcısı ile DB’ye aynı kullanıcı/kimlik ile bağlanıp bağlanmadığını doğrulayın.

9) Cron ile etkileşen servisler: Docker, systemd timer, container restart

Bazı sistemlerde “cron” yerine “systemd timer” veya “Docker container içi cron” hedeflenir. Hangi katmanda çalıştığınızı bilmek gerekir.

Eğer Docker kullanıyorsanız

• Cron komutu host’ta mı çalışıyor yoksa container içinde mi?
• Container durduğunda cron tetiklenir ama hedef süreç yoktur.

Bu senaryoda önce container loglarını kontrol edin.

systemd timer kullanıyorsanız cron değil timer devreye alınmış olabilir

Bazı kurulumlarda hem cron hem timer var; beklediğiniz job timer tarafından farklı bir şekilde tetiklenir. Kontrol: - systemctl list-timers --all | grep -i <görev>

10) VDS/VPS panel ayarları ve güvenlik duvarı etkisi (gözden kaçanlar)

Cron’un tetiklenmesi bazen doğru olur; fakat görev dışarı çağrı yaptığında (API, webhook, SMTP) firewall veya ağ kısıtları yüzünden başarısız olur.

Ağ erişimi kontrolü

• Scriptin kullandığı domain/IP’lere bağlantı var mı?
• Sunucuda DNS çözümleme çalışıyor mu?

Net test: - curl -I https://hedef-domain.com (uygulamanın kullandığı endpoint ile) - dig hedef-domain.com veya nslookup

Yetki ve güvenlik (sudoers/SSH key)

Cron job’u SSH ile işlem yapıyorsa: - SSH anahtarlarının doğru kullanıcıya ait olduğunu doğrulayın - known_hosts dosyasının cron kullanıcıda mevcut olup olmadığını kontrol edin

Cron için pratik “tek seferde teşhis” kontrol listesi

Aşağıdaki listeyi sırayla uygulayın; çoğu problem burada çözülür: - systemctl status cron / crond (servis çalışıyor mu?) - grep CRON /var/log/syslog veya /var/log/cron (tetikleme kaydı var mı?) - timedatectl (timezone doğru mu?) - Crontab’ı doğru kullanıcı mı düzenlendi? (sudo crontab -l -u) - Komutlar tam yol ile mi? (/usr/bin/php, /usr/bin/python3) - Çalışma dizini doğru mu? (cd /var/www/app && ...) - Script izinleri doğru mu? (chmod +x) - Çıktı ve hata logu var mı? (>> /var/log/... 2>&1) - Dış bağımlılıklar (DB/API/env) cron kullanıcıda çalışıyor mu? - Güvenlik duvarı / ağ erişimi endpoint’lere gidiyor mu?

Sonuç: Aksiyon planı

Cron’un çalışmaması durumunda en hızlı yol “tek adımda kesinleştirme” yapmaktır: Önce cron daemon çalışıyor mu, sonra logda tetikleniyor mu, ardından PATH/timezone/izin ve çıktı yönlendirme sorunlarını düzeltin. Eğer job log dosyasına yazmıyorsa ve loglarda hiç tetikleme kaydı yoksa servis ve crontab kullanıcı hatası en yüksek olasılıktır. Bu adımları uyguladığınızda, sorunun nerede kilitlendiğini net biçimde görür ve aynı hatayı tekrarlamadan çözümü kalıcı hale getirirsiniz.