cPanel Cron Job Kurulumu: Crontab, WP-Cron ve sistemd Timer Rehberi

cPanel Cron Job Kurulumu: Crontab, WP-Cron ve sistemd Timer Rehberi (2026)

Cron job ayarlamak ilk bakışta üç satır komut gibi görünür: cPanel'de Cron Jobs panelini açarsınız, "Once Per Hour" seçersiniz, komut yazarsınız, kaydedersiniz. Sonra cuma akşamı yedekleme cron'unun haftalardır çalışmadığını fark edersiniz: PHP yolu yanlış, environment değişkenleri eksik, çıktı hiçbir yere yönlendirilmemiş, lockfile yok ve iki kopyası aynı anda çalışıyor. Cron, Unix dünyasının 1975'ten beri kullandığı en basit görünen ama en sinsi servislerinden biri. Bu rehberde cron daemon mimarisi, crontab anatomi, cPanel arayüzü ile yapılandırma, WordPress WP-Cron'u gerçek cron ile değiştirme, sistemd timer modern alternatifi ve flock ile race condition önleme konularını sysadmin + WordPress developer köprü tonuyla anlatıyoruz.

Buyukweb perspektifi: cPanel paylaşımlı hosting paketlerimizde cron job desteği standart; minimum tetik aralığı 15 dakika (sunucu yükü dengesi için). VDS paketlerinde root cron + sistemd timer tam serbest; istediğiniz dakika bazlı tetikleme mümkün. Bu yazıda her iki bağlamı da örneklendiriyoruz. Telefon destek: 0850 302 60 70.

Cron Tarihçesi: Unix V7'den Modern Linux'a

Cron, Bell Labs'ta Brian Kernighan tarafından Unix Version 7 (1977) için yazıldı; sadece root'un çalıştırabildiği tek bir crontab dosyası okurdu. System V Cron (1983) her kullanıcının kendi crontab'ını tutmasını sağladı. Paul Vixie'nin Vixie Cron'u (1987) ise environment variable desteği, MAILTO, daha esnek syntax ve modern Linux dağıtımlarının dayandığı çekirdek implementasyon oldu — bugün çoğu sistemde gördüğünüz crond aslında Vixie cron'un dolayı bir torunu.

2026 itibariyle Linux dünyasında üç ana cron implementasyonu var:

İsim	Dağıtım	Özellik
vixie-cron	Klasik (artık az)	Vixie'nin orijinal kodu; basit, kararlı
cronie	RHEL, AlmaLinux, Rocky	Vixie fork; SELinux + anacron entegrasyonu
fcron	Niş kullanım	Sleep state yakalar; randomized delay
systemd timers	Modern Linux	Cron yerine systemd .timer unit'leri

cPanel sunucularında çoğunlukla cronie çalışır; servis adı crond. cPanel'in "Cron Jobs" arayüzü, kullanıcının crontab dosyasına yazan bir grafik wrapper'dan ibarettir — crontab -e ile SSH'den de aynı dosyayı düzenleyebilirsiniz.

Crontab Anatomi: 5 Alan + Komut

Crontab satırının formatı:

* * * * * komut
│ │ │ │ │
│ │ │ │ └── Haftanın günü (0-7, 0 ve 7 = Pazar)
│ │ │ └──── Ay (1-12 veya jan-dec)
│ │ └────── Ayın günü (1-31)
│ └──────── Saat (0-23)
└────────── Dakika (0-59)

Özel Karakterler

Karakter	Anlam	Örnek
*	Her değer	* dakika alanında = her dakika
,	Liste	1,15,30 = 1., 15., 30. dakika
-	Aralık	9-17 = 9'dan 17'ye kadar
/	Adım	*/5 = her 5 birimde
?	Belirsiz (POSIX dışı)	Cronie destekler, vixie desteklemez

Özel Tanımlayıcılar (@-Strings)

Vixie cron, okunabilirlik için kısayollar sunar:

String	Karşılığı
@reboot	Sistem her açıldığında bir kez
@yearly veya @annually	0 0 1 1 * — Yılda bir kez
@monthly	0 0 1 * * — Ayda bir
@weekly	0 0 * * 0 — Haftada bir (Pazar)
@daily veya @midnight	0 0 * * * — Günde bir
@hourly	0 * * * * — Saatte bir

@reboot özellikle VDS'lerde değerli: sistem her açıldığında çalıştırılan başlangıç betikleri (örneğin: kuyruk worker başlatma, dev ortamda Redis warm-up).

Pratik Crontab Örnekleri (Açıklamalı)

Crontab	Anlam
0 3 * * * /home/user/backup.sh	Her gün 03:00'te yedekleme
*/15 * * * * /usr/local/bin/php cron.php	Her 15 dakikada bir
0 * * * * php email-queue.php	Her saat başı e-posta kuyruğu işle
0 6 * * 1 /home/user/weekly-report.sh	Pazartesi 06:00 raporu
30 2 1 * * /home/user/monthly-clean.sh	Her ayın 1'i 02:30
0 9-17 * * 1-5 /script.sh	Hafta içi 09:00-17:00 saat başı
@reboot /home/user/startup.sh	Sistem açıldığında
0 0 1,15 * * /script.sh	Ayın 1'inde ve 15'inde gece yarısı
*/30 9-18 * * 1-5 /script.sh	Hafta içi 09-18 her 30 dk

Bir nüans: */7 ifadesi her 7 birimde değil, 0'dan başlayan adımlar anlamına gelir. Yani */7 * * * * dakika 0, 7, 14, 21, 28, 35, 42, 49, 56 üzerinde tetiklenir; 56'dan sonraki tetik bir sonraki saatin 0'ında. 60 dakika 7'ye tam bölünmediği için ritim her saat sıfırlanır. Ritim bozulmasını önlemek için 60'ı tam bölen değerler (1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30) tercih edilir.

cPanel'de Cron Job Yapılandırması

Cron Jobs Sayfasına Erişim

cPanel ana ekranında Advanced > Cron Jobs menüsünden ulaşılır. Sayfa üç bölümden oluşur:

1. Cron Email — cron çıktısının gönderileceği e-posta
2. Add New Cron Job — yeni görev formu
3. Current Cron Jobs — mevcut görev listesi

Cron Email (MAILTO Eşdeğeri)

"Cron Email" kutusuna bir adres yazarsanız cron çıktısı (varsa) o adrese mail olur. Bu, cron'un üstüne [email protected] yazmakla aynı işi yapar. Yoğun cron'larda mail kutusunu kirletmemek için ya alanı boş bırakın ya da komutun çıktısını yönlendirin (>> /home/user/cron.log 2>&1).

Common Settings Dropdown

cPanel'in "Common Settings" dropdown'u şu hazır şablonları sunar:

• Once Per Minute
• Once Per Five Minutes
• Twice Per Hour
• Once Per Hour
• Twice Per Day
• Once Per Day
• Once Per Week
• 1st and 15th
• Once Per Month
• Once Per Year

Dropdown 5 alanı otomatik doldurur; manuel düzenleyerek ince ayar yapabilirsiniz.

Buyukweb Paylaşımlı Paketlerde 15 Dakika Limiti

Buyukweb cPanel hosting paketlerinde minimum cron tetik aralığı 15 dakika. Bu kısıt teknik değil politik: paylaşımlı sunucuda saniye/dakika bazlı cron'lar I/O ve CPU darboğazı yaratır, diğer hesaplar etkilenir. WP-Cron disable + her dakika gerçek cron ihtiyacınız varsa VDS paketleri uygun çözüm (/vds-sunucu veya /paket-karsilastirma).

WHM Tarafı (Reseller / Sunucu Yönetimi)

Reseller veya VDS+WHM sahipleri WHM > Cron Configuration üzerinden:

• Toplu cron limit yapılandırma
• /var/log/cron rotasyonu
• Anacron / cronie servis durumu
• Hesap bazlı cron sayısı sınırı

ayarlayabilir.

Komut Yazarken Dikkat Edilecekler

Cron environment'ı çok kısıtlıdır: PATH, USER, HOME, SHELL değişkenleri shell'de gördüğünüzden farklıdır. Bu yüzden:

Tam Yol Kullanın

# YANLIS (cron'da bulamayabilir):
* * * * * php /home/user/cron.php

# DOGRU:
* * * * * /usr/local/bin/php /home/user/public_html/cron.php

PHP binary'sinin tam yolunu bulmak için SSH'de which php veya type php çalıştırın. cPanel'de yaygın yollar:

Yol	Anlamı
/usr/local/bin/php	cPanel default (genelde EA-PHP en üst sürüm)
/usr/local/bin/ea-php83	EasyApache PHP 8.3 spesifik
/opt/cpanel/ea-php83/root/usr/bin/php	EA-PHP 8.3 full path
/usr/bin/php	Sistem PHP (genelde eski)

CGI/Web PHP vs CLI PHP Farkı

cPanel'de "PHP Selector" panelinden seçtiğiniz sürüm web sunucusu PHP. Cron'un kullandığı CLI PHP farklı olabilir. SSH'de:

which php-cli
/usr/local/bin/php -v
/usr/local/bin/php -i | grep "Loaded Configuration File"

Domain bazlı CLI PHP için cPanel'in MultiPHP Manager + .bashrc PATH ayarı kombosu gerekebilir; bilinmeyen şey: web sürümü 8.3 ama cron'unuz 7.4 ile çalışıyorsa eklentiler değişik davranır.

Mutlak Path Script

# YANLIS:
* * * * * ./cron.php

# DOGRU:
* * * * * /usr/local/bin/php /home/user/public_html/cron.php

./ ifadesi cron'un başlangıç dizinine (genelde HOME) göredir; betiğin orada olduğunu garanti edemezsiniz.

Çıktı Yönlendirme

İfade	Anlamı
>> /path/log	stdout'u log'a ekle
2>> /path/err	stderr'i err'e ekle
>> /path/log 2>&1	stdout + stderr aynı log'a
> /dev/null 2>&1	Her şeyi sustur (genelde KÖTÜ — hata yakalanamaz)

Pratik tavsiye: Üretimde > /dev/null 2>&1 kullanmayın. Log dosyasına yazıp logrotate ile haftalık temizleyin; hata anında diagnostic için kayıt elinizde olur.

WordPress WP-Cron Gerçeği

WordPress'in dahili görev planlayıcısı wp-cron.php, sandığınız gibi gerçek cron değildir: bir ziyaretçi siteyi her açtığında WordPress son cron kontrolünü ne zaman yaptığını bakar, geçtiyse wp-cron.php URL'sine spawned bir HTTP isteği atar. Bu yaklaşımın iki sorunu var:

1. Düşük trafikli sitede gecikme: Ziyaret yoksa cron çalışmaz. Gece 03:00'te yedek alacağınız iş, hiç ziyaretçi olmazsa ertesi sabah çalışır.
2. Yüksek trafikli sitede yük: Her ziyaretin sonunda cron tetik kontrolü ek I/O. WooCommerce gibi Action Scheduler kullanan eklentiler, her sayfa yüklemesinde 50-100 scheduled action kontrol eder.

Adım 1: WP-Cron'u Devre Dışı Bırakın

wp-config.php dosyasına /* That's all, stop editing! */ satırının ÜSTÜNE ekleyin:

define('DISABLE_WP_CRON', true);

Bu, otomatik tetiği kapatır; cron olayları "due" durumda bekler.

Adım 2: Gerçek Cron ile Tetikleyin

cPanel Cron Jobs'a şu satırı ekleyin (15 dakikada bir — paylaşımlı limit):

*/15 * * * * cd /home/user/public_html && /usr/local/bin/php -q wp-cron.php > /dev/null 2>&1

Veya WP-CLI ile (modern yaklaşım — daha temiz):

*/15 * * * * cd /home/user/public_html && /usr/local/bin/php /home/user/wp-cli.phar cron event run --due-now >> /home/user/wp-cron.log 2>&1

--due-now zamanı gelmiş tüm olayları çalıştırır; bekleyenlere dokunmaz.

WooCommerce Action Scheduler Bağlamı

WooCommerce'in Action Scheduler kuyruğu, yoğun mağazada saatte binlerce action biriktirebilir (e-posta gönderim, raporlama, stok güncelleme). WP-Cron disable + 15 dakikalık gerçek cron + Action Scheduler "Async Runner" konfigürasyonu kombosu darboğazı çözer. Eklenti panelinden veya wp action-scheduler queue (WP-CLI) ile durum görülür.

Dürüst Not: Disable Etmeden Önce Düşünün

Eğer site trafik yüksek + yedek/zamanlanmış post sayısı az ise WP-Cron default davranışı yeterli olabilir; gereksiz yere disable etmeyin. Disable kararı kuyruk dolu + gecikme şikayeti olduğunda mantıklı.

MAILTO ve Log Stratejisi

Crontab başına ekleyebileceğiniz environment değişkenleri:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
[email protected]
TZ=Europe/Istanbul

# Bunun altında cron tanımları:
0 3 * * * /home/user/backup.sh
*/30 * * * * /home/user/healthcheck.sh

MAILTO boş bırakılırsa (MAILTO="") hiç mail gönderilmez. cPanel arayüzü "Cron Email" kutusunu yönetir; manuel crontab -e ile koyduğunuz MAILTO cPanel ayarıyla çakışırsa son düzenleme galip gelir.

Log Tabanlı Yaklaşım (MAILTO Yerine)

Yüksek frekanslı cron'larda mail yerine log tercih edilir:

*/5 * * * * /home/user/script.sh >> /home/user/logs/script.log 2>&1

logrotate yapılandırması (/etc/logrotate.d/user-scripts):

/home/user/logs/*.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Bu kurulum logları 4 hafta tutar, eski olanları gzip'ler.

Cron Job Debugging Rehberi

"Komut SSH'de çalışıyor ama cron'da çalışmıyor" sorunu cron deneyiminin %80'i. Sistematik debugging adımları:

Adım 1: Mevcut Crontab'ı Listele

crontab -l

cPanel'de Cron Jobs sayfasında listelenen satırlar aynısı.

Adım 2: Sistem Log'larına Bak

# Eski init (cronie):
sudo tail -f /var/log/cron

# systemd:
sudo journalctl -u crond -f
sudo journalctl -u cron -f   # Debian/Ubuntu

Cron başladığında ve bittiğinde sistem log'a satır düşer. "Started" gördüyseniz cron tetiklendi; ama çıktı/hata için kendi log'unuza bakın.

Adım 3: Cron'un Gördüğü Environment'ı Yakala

Bir test satırı ekleyin:

* * * * * /usr/bin/printenv > /tmp/cron-env.txt 2>&1

Bir dakika bekleyin, sonra:

cat /tmp/cron-env.txt

PATH'in shell'inizden farklı olduğunu, USER ve LANG'in eksik olduğunu göreceksiniz. Eksik değişkenleri crontab başına ekleyin.

Adım 4: Manuel Çalıştır + cron-shell

Komutu cron'un göreceği shell'de simüle edin:

# Shell environment'i sıfırla, sonra çalıştır:
env -i bash -c 'PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/home/user /home/user/script.sh'

Eğer bu komut başarısızsa, cron'da da başarısız olacak. Eksik environment veya yolu işaret eder.

Adım 5: Script İçinde Kapsamlı Log

#!/bin/bash
exec > >(tee -a /home/user/script.log) 2>&1
echo "=== Started: $(date) ==="
echo "USER: $USER"
echo "PWD: $PWD"
echo "PATH: $PATH"
# ... asıl iş ...
echo "=== Done: $(date) ==="

Bu yapı script'in her çalıştırılışında zaman damgalı kayıt bırakır.

Yaygın Sorunlar ve Çözümleri

"Command not found"

cron'un PATH'i eksik. Çözüm: komutun tam yolunu yazın veya crontab başına PATH= tanımlayın.

"Permission denied"

Script'in execute bit'i yok:

chmod +x /home/user/script.sh
ls -l /home/user/script.sh   # -rwxr--r--

Script'in owner'ı cron user'ı mı? Farklıysa, ya owner'ı değiştirin ya da bash /home/user/script.sh şeklinde çağırın.

"% sign" Sorunu

Crontab'da % özel karakter — yorum başlangıcı sayılır. date +%Y%m%d gibi format string'leri kullanırken:

# YANLIS:
0 3 * * * /home/user/backup-$(date +%Y%m%d).sh

# DOGRU (backslash escape):
0 3 * * * /home/user/backup-$(date +\%Y\%m\%d).sh

Saat Dilimi Sorunu

Sunucu UTC'de, siz Türkiye saatine göre düşünüyorsunuz. Crontab başına:

TZ=Europe/Istanbul

Veya komut içinde override:

0 3 * * * TZ=Europe/Istanbul /home/user/backup.sh

Long-Running Script Overlap

Komutun tek seferi bir önceki bitmeden başlarsa veritabanı kilidi, race condition, çift e-posta gibi sorunlar çıkar. flock çözüm:

*/15 * * * * flock -n /tmp/myscript.lock /home/user/script.sh

-n flag'i: kilit alınamazsa beklemeden çık. Eski instance hâlâ koşuyorsa bu tetik atlanır. flock util-linux paketinde gelir, neredeyse her sistemde mevcut.

sistemd Timer: Modern Cron Alternatifi

systemd, RHEL 7 / Ubuntu 16.04'ten beri Linux'ta default init sistemi. systemd timer unit'leri cron'a alternatif sunar — daha güçlü, daha entegre, daha debug edilebilir. Buyukweb VDS müşterilerinin cron yerine sistemd timer'ı tercih etmesini öneriyoruz.

Timer Avantajları

Özellik	cron	sistemd timer
Log entegrasyonu	Ayrı log	journalctl entegre
Dependency	Yok	After=/Wants= ile bağımlı
Resource limit	cgroups yok	MemoryMax, CPUQuota tam destek
Persistent	Kaçırılan tetik kaybolur	Persistent=true ile yakalar
Random delay	Yok	RandomizedDelaySec destekli
Conditional	Yok	ConditionACPower, OnSuccess vs.

Örnek: Günlük Yedekleme Timer'ı

İki dosya gerekir: .service (ne yapılacak) + .timer (ne zaman tetiklenecek).

/etc/systemd/system/yedekleme.service:

[Unit]
Description=Gunluk veritabani yedekleme
After=network.target

[Service]
Type=oneshot
User=postgres
ExecStart=/usr/local/bin/db-backup.sh
StandardOutput=journal
StandardError=journal

/etc/systemd/system/yedekleme.timer:

[Unit]
Description=Gunluk veritabani yedekleme tetigi

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

Aktive et:

sudo systemctl daemon-reload
sudo systemctl enable --now yedekleme.timer
sudo systemctl list-timers

Persistent=true: Sistem kapalıyken kaçırılan tetik bir sonraki açılışta çalışır. RandomizedDelaySec=600: 0-10 dakika rastgele gecikme — birden çok server aynı anda backup yapmasın.

OnCalendar Syntax

systemd kendine has cron benzeri ama daha okunabilir bir syntax kullanır:

OnCalendar	Anlamı
hourly	Saat başı
daily	Gece yarısı
weekly	Pazartesi 00:00
monthly	Ayın 1'i 00:00
*-*-* 03:00:00	Her gün 03:00
Mon..Fri 09:00	Hafta içi 09:00
*-*-1,15 12:00	Her ayın 1'i ve 15'i öğlen
*:0/15	Her 15 dakikada

journalctl ile Log

# Belirli timer log'u:
sudo journalctl -u yedekleme.service -f

# Son 50 satır:
sudo journalctl -u yedekleme.service -n 50

# Bugünkü loglar:
sudo journalctl -u yedekleme.service --since today

journalctl filtreleme, structured query, kolayca aranır log — cron'un /var/log/cron text dosyasına göre çok daha güçlü.

anacron: Laptop / Sık Kapanan Sistemler İçin

Standart cron, sistem kapalıysa kaçırılan tetiği atlar. Laptop'larda veya 7/24 çalışmayan sistemlerde anacron devreye girer: kaçırılan görevleri sistem açıldığında çalıştırır.

/etc/anacrontab örneği:

# period delay job-id command
1       5       cron.daily      run-parts /etc/cron.daily
7       10      cron.weekly     run-parts /etc/cron.weekly
30      15      cron.monthly    run-parts /etc/cron.monthly

period: kaç günde bir; delay: sistem açıldıktan kaç dakika sonra; job-id: tekrarı önleyen kimlik. Sunucularda anacron'a genelde gerek yoktur; ama sistemd timer'ın Persistent=true özelliği aynı işi daha temiz yapar.

fcron: Niş Ama Güçlü Cron

fcron, vixie-cron'un yapamadığı şeyleri yapar:

• Sistem uyuyorken kaçırılan tetikleri yakala
• Tetik bazlı önceliklendirme
• nice değeri spesifik tetik için
• "First Monday of month" gibi karmaşık zamanlama
• Rastgele zaman delay (Vixie'de yok)

Modern Linux dağıtımlarının çoğunda sistemd timer fcron'un yerini aldığı için fcron artık niş; ama eski sistemlerde veya sistemd istemeyen ortamlarda hâlâ tercih edilir.

Buyukweb Hosting Bağlamı: Hangi Cron Hangi Pakette?

cPanel Paylaşımlı (/cpanel-web-hosting)

• cPanel Cron Jobs arayüzü standart
• Minimum tetik 15 dakika (sunucu yükü politikası)
• MAILTO destekli — Cron Email alanı doldurulduğunda otomatik
• crontab -e SSH ile alternatif
• WP-Cron disable + 15 dk gerçek cron senaryosu desteklenir
• sistemd timer YOK (paylaşımlı sunucu, root erişimi yok)

VDS (/vds-sunucu)

• Tam root cron + sistemd timer serbest
• Minimum tetik dakika bazlı (1 dakikadan kısa cron tasarımı pratik değil, ama yapılabilir)
• Buyukweb destek ekibi başlangıç sistemd unit yapılandırması için yardımcı olur (Bursa Tier 3 veri merkezi support)
• VDS'te kendi backup cron'ları kurabilirsiniz (örneğin günlük pg_dump veya mysqldump); Buyukweb JetBackup haftalık ek olarak çalışmaya devam eder

Yedekleme Cron Stratejisi

cPanel paketlerinde Buyukweb JetBackup haftalık snapshot çalışır (otomatik); bunun üstüne kendi günlük mysqldump cron'u eklemek için:

0 3 * * * cd /home/user && mysqldump -u dbuser -p'dbpass' dbname | gzip > backups/db-\$(date +\%Y\%m\%d).sql.gz 2>> backups/dump.log

Sonra 14 günden eski dump'ları siler:

0 4 * * * find /home/user/backups -name 'db-*.sql.gz' -mtime +14 -delete

Bu kombo: haftalık JetBackup (Buyukweb) + günlük rolling MySQL dump (siz) = veri kaybı toleransı 24 saatten kısa.

Sık Sorulan Sorular

cPanel Cron Jobs'tan eklediğim job, crontab -l ile listelenmiyor — neden?

cPanel arayüzü kullanıcının crontab dosyasına yazar. SSH'de crontab -l aynı dosyayı okur. Listelenmiyorsa: ya cPanel sayfasını kaydetmemişsiniz ya da farklı kullanıcı oturumundasınız (root vs. cpanel user). whoami ile aktif kullanıcıyı kontrol edin.

WP-Cron'u disable ettim ama scheduled post'lar yayınlanmıyor — sorun nerede?

Gerçek cron job ekleyip eklemediğinizi kontrol edin. Disable tek başına yetmez — eklenti ve scheduled olayların çalışması için cron'un tetiklenmesi şart. cPanel Cron Jobs sayfasında wp-cron.php veya wp cron event run --due-now satırı görünmüyorsa, eklemeniz lazım.

Cron job çalışıyor ama mail gelmiyor — Cron Email doldurulmuş halde?

İki olası neden: (1) Komut output üretmiyor; cron output yoksa mail göndermez. (2) Sunucudan dışarı SMTP engelli; cPanel kendi MTA'sı üzerinden gönderir ama bazı sunucularda Outbound SMTP limit/blacklist var. Test: echo "test" | mail -s "test" [email protected] shell'de çalışıyor mu?

Buyukweb cPanel paketinde 1 dakikada bir cron lazım — yapabilir miyim?

Paylaşımlı pakette politik kısıt 15 dakika; daha sık cron için VDS uygun. VDS'te dakika bazlı serbestsiniz; sistemd timer veya cron ile saniye altı tetikleme bile teknik olarak mümkün (mantıklı değil ama). Telefon: 0850 302 60 70.

sistemd timer mi, cron mu — yeni VDS kurulumunda hangisini seçmeliyim?

Modern Linux dağıtımındaysanız (Ubuntu 22.04+, AlmaLinux 9, Rocky 9) sistemd timer önerilir: journalctl entegre log, dependency yönetimi, persistent (kaçırılan tetik yakalama), randomized delay. Eski betikleri taşımak istemiyorsanız cron'da kalmak da geçerli; iki sistem yan yana çalışabilir, çakışmaz.

Sonuç

Cron, görünüşte basit ama detayda derin bir servis: 5 alanlık syntax öğrenmek 10 dakikadır, ama PATH problemini, % escape'i, race condition'ı, environment farkını, MAILTO yönlendirmeyi anlamak haftalar alır. Bu rehberin ana mesajı: tam yol kullanın, çıktıyı yönlendirin, flock ile koruyun, log üretin — bu dört prensibi uygularsanız cron'un yarattığı sürprizlerin %90'ı önlenir. WordPress sitelerde WP-Cron disable + gerçek cron kombosu yüksek trafikte performans rahatlığı verir. VDS müşterileri sistemd timer'a geçtikçe debug, log, dependency yönetimi kıyaslanamaz şekilde kolaylaşır.

Buyukweb cPanel paketlerinde 15 dakika minimum, MAILTO destekli, panel arayüzünden kolay cron yönetimi; VDS paketlerinde tam root + sistemd timer serbestliği. Hangi paketin sizin ihtiyacınıza uyacağını paket karşılaştırma sayfasından inceleyebilir, teknik soruları için 0850 302 60 70 destek hattımızı arayabilirsiniz.

---

İlgili Büyükweb Hizmetleri

Cron job ve zamanlanmış görev ihtiyaçlarınız için Buyukweb paketleri:

• cPanel Web Hosting — 15 dk minimum cron, panel arayüzünden yönetim
• VDS Sunucu — Root cron + sistemd timer + dakika bazlı serbest
• WordPress Hosting — WP-Cron disable destekli, gerçek cron hazır
• Plesk Web Hosting — Plesk Scheduled Tasks panelinden
• Hosting Paket Karşılaştırma

Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.