<![CDATA[Dataweb Forum - Hosting & Sunucu]]> https://dataweb.com.tr/forum/ Sun, 06 Sep 2026 04:26:27 +0000 MyBB <![CDATA[Cron Job Çalışmıyor: Önce Neyi Kontrol Etmek Gerekir?]]> https://dataweb.com.tr/forum/thread-46.html Wed, 02 Sep 2026 13:07:03 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-46.html
Amaç şu üç soruyu ayrı ayrı cevaplamak:

Kod:
1. Zamanlayıcı gerçekten tetikleniyor mu? 2. PHP/script gerçekten çalışabiliyor mu? 3. Script çalışıyor ama uygulama içinde mi hata veriyor?

Aşağıdaki adımlar teknik bilmeyen birinin de sırayla uygulayabileceği şekilde hazırlanmıştır.

1) Cron gerçekten tetikleniyor mu? En basit dosya testi

Önce uygulamanızı hiç çalıştırmadan yalnız cron servisinin tetiklenip tetiklenmediğini test edin.

Yöntem A — PHP dosyasıyla test

Dosya yöneticisinde sitenizin `public_html` klasörüne girin.

Yeni bir dosya oluşturun:

Kod:
cron-test.php

İçine şunu yazın:

Kod:
<?php file_put_contents( __DIR__ . '/cron-test.log', date('Y-m-d H:i:s') . PHP_EOL, FILE_APPEND );

Kaydedin.

Şimdi hosting panelindeki Cron Jobs bölümünde geçici bir görev oluşturun.

Örneğin panel PHP türünü kendisi seçtiriyorsa:
- PHP sürümü: sitenizle aynı sürüm
- dosya: `public_html/cron-test.php`
- zamanlama: her 5 dakikada bir

Özel komut kabul ediyorsa örnek mantık:

Kod:
/usr/bin/php /home/KULLANICI/public_html/cron-test.php

Bazı hostinglerde PHP yolu farklı olabilir; aşağıdaki 2. bölümde bunu nasıl bulacağımızı anlatıyorum.

5-10 dakika bekleyin.

Dosya yöneticisini yenileyin.

Şu dosya oluşmuş olmalı:

Kod:
cron-test.log

İçini açın.

Örnek:

Kod:
2026-09-02 15:05:01 2026-09-02 15:10:01

Bu satırlar oluşuyorsa cron zamanlayıcısı çalışıyor demektir. Artık sorun cron servisinde değil, asıl scriptinizdedir.

Dosya hiç oluşmuyorsa:
- komut yanlış,
- PHP yolu yanlış,
- dosya yolu yanlış,
- cron henüz tetiklenmedi,
- panel görevi kaydetmemiş

olabilir.

Test bitince `cron-test.php` ve `cron-test.log` dosyalarını silin.

2) Panelin kullandığı PHP / CLI yolu doğru mu?

Web sitesinin PHP sürümü ile cron’un kullandığı komut satırı PHP’si aynı olmayabilir.

Örneğin web siteniz PHP 8.3 çalıştırırken cron:

Kod:
/usr/bin/php

ile PHP 8.1 çalıştırıyor olabilir.

Hostinger benzeri panellerde Cron Job oluştururken “PHP” seçeneği varsa panel çoğu zaman PHP çalıştırıcısının ilk kısmını otomatik getirir. Örneğin:

Kod:
/opt/alt/php83/usr/bin/lsphp

veya sunucuya göre:

Kod:
/usr/bin/php

görebilirsiniz.

Nereden bakılır?

Hosting paneli → Gelişmiş / Advanced → Cron Jobs / Cron Görevleri.

Mevcut cron kaydının “Komut” alanını açın.

Şuna benzer bir yapı görmelisiniz:

Kod:
PHP_YOLU /home/KULLANICI/domains/site.com/public_html/script.php

PHP yolunu ayrıca SSH erişiminiz varsa doğrulayabilirsiniz:

Kod:
php -v

ve:

Kod:
which php

Örnek çıktı:

Kod:
PHP 8.3.x (cli) /usr/bin/php

Belirli bir yolu kontrol etmek için:

Kod:
/opt/alt/php83/usr/bin/lsphp -v

veya:

Kod:
/usr/bin/php -v

SSH yoksa ne yapacağız?

Cron panelinin PHP seçeneğini kullanın. Panel PHP sürümü seçtiriyorsa elle farklı bir yol yazmak yerine önce o mekanizmayı tercih edin.

Ayrıca geçici test dosyasına:

Kod:
<?php file_put_contents( __DIR__.'/php-cron-info.txt', PHP_VERSION . ' | ' . PHP_SAPI );

yazıp cronla bir kez çalıştırabilirsiniz.

Sonra `php-cron-info.txt` içinde cron’un gördüğü PHP sürümünü okuyabilirsiniz.

Test dosyasını işiniz bitince silin.

3) Script elle çalıştırıldığında hata veriyor mu?

Cron’u devreden çıkarıp asıl PHP dosyasını manuel çalıştırmak çok değerlidir.

SSH varsa

Önce klasöre gidin:

Kod:
cd /home/KULLANICI/domains/site.com/public_html

Sonra:

Kod:
/usr/bin/php yol/script.php

veya hostingin doğru PHP yolu neyse:

Kod:
/opt/alt/php83/usr/bin/lsphp yol/script.php

Hata varsa terminalde görebilirsiniz.

Komut bittikten sonra çıkış kodunu görmek için:

Kod:
echo $?

Genelde `0` başarılı çalışmayı ifade eder; farklı değer script veya çalıştırma hatasına işaret edebilir.

SSH yoksa

Scriptiniz güvenli şekilde web üzerinden çalıştırılmak üzere tasarlanmışsa geçici olarak tarayıcıdan açılabilir. Ancak cron dosyanız yönetim işlemi yapıyorsa herkese açık bırakmayın.

Örneğin uygulamanız token destekliyorsa:

Kod:
https://site.com/cron.php?token=UZUN_GIZLI_TOKEN

gibi korumalı bir test kullanılabilir.

Token veya oturum kontrolü olmayan hassas cron dosyasını sırf test için herkese açık hale getirmeyin.

4) Çalışma dizini yüzünden relative path kırılıyor mu?

Web üzerinden çalışan kod:

Kod:
require 'app/bootstrap.php';

ile çalışırken cron farklı klasörden başlatıldığında dosyayı bulamayabilir.

Daha güvenli yaklaşım:

Kod:
require __DIR__ . '/app/bootstrap.php';

veya dosya alt klasördeyse:

Kod:
require dirname(__DIR__) . '/app/bootstrap.php';

Yani mümkün olduğunca `__DIR__` kullanın.

Alternatif olarak cron komutunda önce klasöre geçebilirsiniz:

Kod:
cd /home/KULLANICI/domains/site.com/public_html && /usr/bin/php yonetim/cron.php

5) Hata çıktısını log dosyasına nasıl yazdırırım?

Cron paneli çıktıyı göstermiyorsa stdout ve stderr’i dosyaya yönlendirin.

Örnek:

Kod:
/usr/bin/php /home/KULLANICI/public_html/cron.php >> /home/KULLANICI/cron-debug.log 2>&1

Buradaki:

Kod:
>>

çıktıyı dosyanın sonuna ekler.

Kod:
2>&1

hata çıktısını da aynı dosyaya gönderir.

Tarih de görmek istiyorsanız:

Kod:
date >> /home/KULLANICI/cron-debug.log /usr/bin/php /home/KULLANICI/public_html/cron.php >> /home/KULLANICI/cron-debug.log 2>&1

Ancak hosting panelinde komut uzunluğu sınırı olabilir. Böyle durumda ayrı bir shell wrapper veya PHP içi loglama tercih edilir.

6) PHP error log nereden kontrol edilir?

Hosting panelinde şu isimleri arayın:

- Error Logs
- PHP Errors
- Logs
- Hata Günlükleri

Dosya yöneticisinde de şu dosyalar bulunabilir:

Kod:
error_log php_error.log logs/

Hata zamanını cron’un çalışması gereken saatle karşılaştırın.

Örneğin:

Kod:
PHP Fatal error: Uncaught mysqli_sql_exception...

gibi bir kayıt varsa cron tetikleniyor fakat uygulama veritabanında çöküyor olabilir.

7) Veritabanı bağlantısı neden cron’da farklı davranabilir?

Web request ile CLI aynı ortam değildir.

Kontrol edin:

- `.env` veya config dosyası doğru yükleniyor mu?
- dosya yolu relative mı?
- DB host `localhost` mı farklı socket mi kullanıyor?
- CLI kullanıcısının gerekli dosyalara erişimi var mı?
- hosting güvenlik politikası CLI bağlantısını sınırlıyor mu?

Basit test için uygulamanızın bootstrap dosyasını yükleyip:

Kod:
SELECT 1

sorgusu çalıştıran geçici tanı sayfası hazırlanabilir.

Üretim verisini değiştirmeyen salt-okunur test tercih edin.

8) Kilit dosyası takılı kaldı mı?

Aynı cron’un iki kez paralel çalışmasını önlemek için bazı scriptler lock file kullanır.

Örnek:

Kod:
app/cron.lock storage/cron.lock /tmp/myapp-cron.lock

Script başında kilit alınıyor ama hata sonrası bırakılmıyorsa sonraki tüm çağrılar “zaten çalışıyor” sanabilir.

Kodu kontrol edin:
- lock ne zaman oluşturuluyor?
- `finally` içinde bırakılıyor mu?
- eski lock için timeout var mı?

Kilit dosyasını ne olduğunu bilmeden silmeyin. Önce scriptin gerçekten çalışmadığını doğrulayın.

9) Cron’un kendisi uzun sürüyor veya timeout oluyor olabilir mi?

Cron işi:
- büyük API çağrısı,
- çok sayıda veritabanı kaydı,
- dış web taraması

yapıyorsa çalışma süresi uzayabilir.

Script içine aşama logları ekleyin:

Kod:
[15:00:01] started [15:00:02] database ok [15:00:04] api request started [15:00:30] api request completed [15:00:31] finished

Log son olarak “api request started” satırında kalıyorsa sorunun hangi aşamada olduğunu anlarsınız.

10) Cron panelindeki boş çıktı ne anlama gelir?

Boş ekran = kesinlikle “çalışmadı” değildir.

Script:
- hiç echo üretmiyor olabilir,
- çıktıyı log dosyasına yönlendiriyor olabilir,
- başarılı çalışıp sessiz bitiyor olabilir.

Bu nedenle asıl kanıt:
- heartbeat zamanı,
- log satırı,
- veritabanındaki son çalışma kaydı,
- oluşturulan test dosyası

gibi gözlemlenebilir bir sonuçtur.

11) Yeni başlayanlar için net teşhis sırası

Aşağıdaki sırayı bozmayın:

  1. Basit `cron-test.php` ile tetikleme var mı?
  2. Cron’un kullandığı PHP sürümü doğru mu?
  3. Asıl script manuel çalışıyor mu?
  4. Absolute path / `__DIR__` kullanılıyor mu?
  5. Hata logu var mı?
  6. Veritabanı bağlantısı çalışıyor mu?
  7. Lock takılı mı?
  8. Uzun işlem/timeout var mı?

12) Destek ekibine ne göndermeliyim?

“Cron çalışmıyor” demek yerine şu bilgileri gönderin:

Kod:
Zamanlama: */15 * * * * Komut: PHP_YOLU /home/.../cron.php PHP sürümü: 8.3 Basit tarih testi: çalışıyor / çalışmıyor Manuel çalıştırma: başarılı / hata mesajı Son log: ... Son başarılı çalışma: ...

Bu bilgiler sorunu çok daha hızlı daraltır.

Güvenlik uyarısı

Cron URL’nizde token varsa ekran görüntüsünde veya forum mesajında token’ın tamamını paylaşmayın. Şifre, veritabanı parolası, API anahtarı ve tam erişim tokenlarını mutlaka gizleyin.

Sizde cron sorunu varsa ilk olarak 1. adımdaki `cron-test.php` testini yapın. Log dosyası oluşuyor mu, oluşmuyorsa paneldeki komutun yapısı nasıl? Gizli bilgileri kapatarak paylaşabilirsiniz.

Dataweb editoryal sürüm: derin anlatım v1.0.0]]>
Amaç şu üç soruyu ayrı ayrı cevaplamak:

Kod:
1. Zamanlayıcı gerçekten tetikleniyor mu? 2. PHP/script gerçekten çalışabiliyor mu? 3. Script çalışıyor ama uygulama içinde mi hata veriyor?

Aşağıdaki adımlar teknik bilmeyen birinin de sırayla uygulayabileceği şekilde hazırlanmıştır.

1) Cron gerçekten tetikleniyor mu? En basit dosya testi

Önce uygulamanızı hiç çalıştırmadan yalnız cron servisinin tetiklenip tetiklenmediğini test edin.

Yöntem A — PHP dosyasıyla test

Dosya yöneticisinde sitenizin `public_html` klasörüne girin.

Yeni bir dosya oluşturun:

Kod:
cron-test.php

İçine şunu yazın:

Kod:
<?php file_put_contents( __DIR__ . '/cron-test.log', date('Y-m-d H:i:s') . PHP_EOL, FILE_APPEND );

Kaydedin.

Şimdi hosting panelindeki Cron Jobs bölümünde geçici bir görev oluşturun.

Örneğin panel PHP türünü kendisi seçtiriyorsa:
- PHP sürümü: sitenizle aynı sürüm
- dosya: `public_html/cron-test.php`
- zamanlama: her 5 dakikada bir

Özel komut kabul ediyorsa örnek mantık:

Kod:
/usr/bin/php /home/KULLANICI/public_html/cron-test.php

Bazı hostinglerde PHP yolu farklı olabilir; aşağıdaki 2. bölümde bunu nasıl bulacağımızı anlatıyorum.

5-10 dakika bekleyin.

Dosya yöneticisini yenileyin.

Şu dosya oluşmuş olmalı:

Kod:
cron-test.log

İçini açın.

Örnek:

Kod:
2026-09-02 15:05:01 2026-09-02 15:10:01

Bu satırlar oluşuyorsa cron zamanlayıcısı çalışıyor demektir. Artık sorun cron servisinde değil, asıl scriptinizdedir.

Dosya hiç oluşmuyorsa:
- komut yanlış,
- PHP yolu yanlış,
- dosya yolu yanlış,
- cron henüz tetiklenmedi,
- panel görevi kaydetmemiş

olabilir.

Test bitince `cron-test.php` ve `cron-test.log` dosyalarını silin.

2) Panelin kullandığı PHP / CLI yolu doğru mu?

Web sitesinin PHP sürümü ile cron’un kullandığı komut satırı PHP’si aynı olmayabilir.

Örneğin web siteniz PHP 8.3 çalıştırırken cron:

Kod:
/usr/bin/php

ile PHP 8.1 çalıştırıyor olabilir.

Hostinger benzeri panellerde Cron Job oluştururken “PHP” seçeneği varsa panel çoğu zaman PHP çalıştırıcısının ilk kısmını otomatik getirir. Örneğin:

Kod:
/opt/alt/php83/usr/bin/lsphp

veya sunucuya göre:

Kod:
/usr/bin/php

görebilirsiniz.

Nereden bakılır?

Hosting paneli → Gelişmiş / Advanced → Cron Jobs / Cron Görevleri.

Mevcut cron kaydının “Komut” alanını açın.

Şuna benzer bir yapı görmelisiniz:

Kod:
PHP_YOLU /home/KULLANICI/domains/site.com/public_html/script.php

PHP yolunu ayrıca SSH erişiminiz varsa doğrulayabilirsiniz:

Kod:
php -v

ve:

Kod:
which php

Örnek çıktı:

Kod:
PHP 8.3.x (cli) /usr/bin/php

Belirli bir yolu kontrol etmek için:

Kod:
/opt/alt/php83/usr/bin/lsphp -v

veya:

Kod:
/usr/bin/php -v

SSH yoksa ne yapacağız?

Cron panelinin PHP seçeneğini kullanın. Panel PHP sürümü seçtiriyorsa elle farklı bir yol yazmak yerine önce o mekanizmayı tercih edin.

Ayrıca geçici test dosyasına:

Kod:
<?php file_put_contents( __DIR__.'/php-cron-info.txt', PHP_VERSION . ' | ' . PHP_SAPI );

yazıp cronla bir kez çalıştırabilirsiniz.

Sonra `php-cron-info.txt` içinde cron’un gördüğü PHP sürümünü okuyabilirsiniz.

Test dosyasını işiniz bitince silin.

3) Script elle çalıştırıldığında hata veriyor mu?

Cron’u devreden çıkarıp asıl PHP dosyasını manuel çalıştırmak çok değerlidir.

SSH varsa

Önce klasöre gidin:

Kod:
cd /home/KULLANICI/domains/site.com/public_html

Sonra:

Kod:
/usr/bin/php yol/script.php

veya hostingin doğru PHP yolu neyse:

Kod:
/opt/alt/php83/usr/bin/lsphp yol/script.php

Hata varsa terminalde görebilirsiniz.

Komut bittikten sonra çıkış kodunu görmek için:

Kod:
echo $?

Genelde `0` başarılı çalışmayı ifade eder; farklı değer script veya çalıştırma hatasına işaret edebilir.

SSH yoksa

Scriptiniz güvenli şekilde web üzerinden çalıştırılmak üzere tasarlanmışsa geçici olarak tarayıcıdan açılabilir. Ancak cron dosyanız yönetim işlemi yapıyorsa herkese açık bırakmayın.

Örneğin uygulamanız token destekliyorsa:

Kod:
https://site.com/cron.php?token=UZUN_GIZLI_TOKEN

gibi korumalı bir test kullanılabilir.

Token veya oturum kontrolü olmayan hassas cron dosyasını sırf test için herkese açık hale getirmeyin.

4) Çalışma dizini yüzünden relative path kırılıyor mu?

Web üzerinden çalışan kod:

Kod:
require 'app/bootstrap.php';

ile çalışırken cron farklı klasörden başlatıldığında dosyayı bulamayabilir.

Daha güvenli yaklaşım:

Kod:
require __DIR__ . '/app/bootstrap.php';

veya dosya alt klasördeyse:

Kod:
require dirname(__DIR__) . '/app/bootstrap.php';

Yani mümkün olduğunca `__DIR__` kullanın.

Alternatif olarak cron komutunda önce klasöre geçebilirsiniz:

Kod:
cd /home/KULLANICI/domains/site.com/public_html && /usr/bin/php yonetim/cron.php

5) Hata çıktısını log dosyasına nasıl yazdırırım?

Cron paneli çıktıyı göstermiyorsa stdout ve stderr’i dosyaya yönlendirin.

Örnek:

Kod:
/usr/bin/php /home/KULLANICI/public_html/cron.php >> /home/KULLANICI/cron-debug.log 2>&1

Buradaki:

Kod:
>>

çıktıyı dosyanın sonuna ekler.

Kod:
2>&1

hata çıktısını da aynı dosyaya gönderir.

Tarih de görmek istiyorsanız:

Kod:
date >> /home/KULLANICI/cron-debug.log /usr/bin/php /home/KULLANICI/public_html/cron.php >> /home/KULLANICI/cron-debug.log 2>&1

Ancak hosting panelinde komut uzunluğu sınırı olabilir. Böyle durumda ayrı bir shell wrapper veya PHP içi loglama tercih edilir.

6) PHP error log nereden kontrol edilir?

Hosting panelinde şu isimleri arayın:

- Error Logs
- PHP Errors
- Logs
- Hata Günlükleri

Dosya yöneticisinde de şu dosyalar bulunabilir:

Kod:
error_log php_error.log logs/

Hata zamanını cron’un çalışması gereken saatle karşılaştırın.

Örneğin:

Kod:
PHP Fatal error: Uncaught mysqli_sql_exception...

gibi bir kayıt varsa cron tetikleniyor fakat uygulama veritabanında çöküyor olabilir.

7) Veritabanı bağlantısı neden cron’da farklı davranabilir?

Web request ile CLI aynı ortam değildir.

Kontrol edin:

- `.env` veya config dosyası doğru yükleniyor mu?
- dosya yolu relative mı?
- DB host `localhost` mı farklı socket mi kullanıyor?
- CLI kullanıcısının gerekli dosyalara erişimi var mı?
- hosting güvenlik politikası CLI bağlantısını sınırlıyor mu?

Basit test için uygulamanızın bootstrap dosyasını yükleyip:

Kod:
SELECT 1

sorgusu çalıştıran geçici tanı sayfası hazırlanabilir.

Üretim verisini değiştirmeyen salt-okunur test tercih edin.

8) Kilit dosyası takılı kaldı mı?

Aynı cron’un iki kez paralel çalışmasını önlemek için bazı scriptler lock file kullanır.

Örnek:

Kod:
app/cron.lock storage/cron.lock /tmp/myapp-cron.lock

Script başında kilit alınıyor ama hata sonrası bırakılmıyorsa sonraki tüm çağrılar “zaten çalışıyor” sanabilir.

Kodu kontrol edin:
- lock ne zaman oluşturuluyor?
- `finally` içinde bırakılıyor mu?
- eski lock için timeout var mı?

Kilit dosyasını ne olduğunu bilmeden silmeyin. Önce scriptin gerçekten çalışmadığını doğrulayın.

9) Cron’un kendisi uzun sürüyor veya timeout oluyor olabilir mi?

Cron işi:
- büyük API çağrısı,
- çok sayıda veritabanı kaydı,
- dış web taraması

yapıyorsa çalışma süresi uzayabilir.

Script içine aşama logları ekleyin:

Kod:
[15:00:01] started [15:00:02] database ok [15:00:04] api request started [15:00:30] api request completed [15:00:31] finished

Log son olarak “api request started” satırında kalıyorsa sorunun hangi aşamada olduğunu anlarsınız.

10) Cron panelindeki boş çıktı ne anlama gelir?

Boş ekran = kesinlikle “çalışmadı” değildir.

Script:
- hiç echo üretmiyor olabilir,
- çıktıyı log dosyasına yönlendiriyor olabilir,
- başarılı çalışıp sessiz bitiyor olabilir.

Bu nedenle asıl kanıt:
- heartbeat zamanı,
- log satırı,
- veritabanındaki son çalışma kaydı,
- oluşturulan test dosyası

gibi gözlemlenebilir bir sonuçtur.

11) Yeni başlayanlar için net teşhis sırası

Aşağıdaki sırayı bozmayın:

  1. Basit `cron-test.php` ile tetikleme var mı?
  2. Cron’un kullandığı PHP sürümü doğru mu?
  3. Asıl script manuel çalışıyor mu?
  4. Absolute path / `__DIR__` kullanılıyor mu?
  5. Hata logu var mı?
  6. Veritabanı bağlantısı çalışıyor mu?
  7. Lock takılı mı?
  8. Uzun işlem/timeout var mı?

12) Destek ekibine ne göndermeliyim?

“Cron çalışmıyor” demek yerine şu bilgileri gönderin:

Kod:
Zamanlama: */15 * * * * Komut: PHP_YOLU /home/.../cron.php PHP sürümü: 8.3 Basit tarih testi: çalışıyor / çalışmıyor Manuel çalıştırma: başarılı / hata mesajı Son log: ... Son başarılı çalışma: ...

Bu bilgiler sorunu çok daha hızlı daraltır.

Güvenlik uyarısı

Cron URL’nizde token varsa ekran görüntüsünde veya forum mesajında token’ın tamamını paylaşmayın. Şifre, veritabanı parolası, API anahtarı ve tam erişim tokenlarını mutlaka gizleyin.

Sizde cron sorunu varsa ilk olarak 1. adımdaki `cron-test.php` testini yapın. Log dosyası oluşuyor mu, oluşmuyorsa paneldeki komutun yapısı nasıl? Gizli bilgileri kapatarak paylaşabilirsiniz.

Dataweb editoryal sürüm: derin anlatım v1.0.0]]> <![CDATA[Hosting Seçerken Disk Alanından Daha Önemli Hangi Değerler Var?]]> https://dataweb.com.tr/forum/thread-23.html Thu, 20 Aug 2026 11:10:26 +0000 Kadir]]> https://dataweb.com.tr/forum/thread-23.html
Ayrıca yedeklerin gerçekten geri yüklenebilir olması, staging imkânı ve kötü amaçlı yazılım taraması operasyon açısından kritik.

Bir hosting sağlayıcısını değerlendirirken siz ilk olarak hangi teknik limiti soruyorsunuz? Paylaşımlı hostingden VPS’e geçiş kararını hangi sinyal veriyor?]]>
Ayrıca yedeklerin gerçekten geri yüklenebilir olması, staging imkânı ve kötü amaçlı yazılım taraması operasyon açısından kritik.

Bir hosting sağlayıcısını değerlendirirken siz ilk olarak hangi teknik limiti soruyorsunuz? Paylaşımlı hostingden VPS’e geçiş kararını hangi sinyal veriyor?]]>