CentOS/Rocky Linux'ta Cron Job Oluşturma Rehberi

CentOS 7 sürümünün ömrünü tamamlamasının (End of Life - EOL) ardından kurumsal sistem yönetiminde CentOS Stream 9, Rocky Linux 8/9 ve AlmaLinux 8/9 dağıtımları ön plana çıkmıştır. Red Hat Enterprise Linux (RHEL) tabanlı bu dağıtımlarda sistem görevlerinin periyodik yürütülmesi, güvenilir otomasyon altyapısının temel taşını oluşturur. Web sitelerinin veritabanı yedekleri, e-posta gönderim kuyrukları, disk temizleme rutinleri ve sistem izleme betikleri cron mekanizması üzerinden çalıştırılır. Temel kavramları incelemek isterseniz kapsamlı cron job nedir rehberimize göz atabilirsiniz.

RHEL ekosisteminde arka plan görevlerini yönetirken Debian veya Ubuntu alışkanlıklarıyla hareket etmek yaygın yapılandırma hatalarına yol açar. Paket adı, sistem servisinin adı, kullanıcı crontab dosyalarının saklandığı dizin ve log dosyasının konumu tamamen farklıdır. Bununla birlikte RHEL tabanlı sistemlerde varsayılan olarak devrede olan SELinux (Security-Enhanced Linux) güvenlik modülü, betiklerin çalıştırılma izinlerinde doğrudan belirleyicidir. Bu rehberde CentOS Stream, Rocky Linux ve AlmaLinux üzerinde cron yönetimini tüm teknik ayrıntılarıyla ele alıyoruz.

Genel Linux standartlarına hakim olmak için hazırladığımız Linux cron job makalesinden farklı olarak burada RHEL mimarisinin çekirdeğinde yer alan cronie paketini, crond servisini, erişim denetim listelerini ve SELinux kaynaklı izin blokajlarının çözüm yollarını adım adım inceleyeceğiz.

RHEL Tabanlı Sistemlerde (CentOS, Rocky Linux, AlmaLinux) Cron Mimarisi

RHEL dağıtımlarında cron görevlerini yürüten çekirdek yazılım cronie paketidir. cronie, klasik Paul Vixie cron projesinin modern bir çatallamasıdır (fork). Bu paketin en büyük avantajı, PAM (Pluggable Authentication Modules) desteği ve SELinux mimarisiyle derinlemesine entegre çalışmasıdır. Sistemde arka plan hizmeti olarak çalışan daemon, Ubuntu dünyasındaki gibi cron değil, crond.service adını taşır.

CentOS ve Rocky Linux sistemlerinde zamanlanmış görevlerin dosya ve dizin yerleşimi kendine has bir hiyerarşiye sahiptir. Aşağıdaki karşılaştırma tablosu, iki popüler dağıtım ailesi arasındaki mimari farklılıkları net biçimde özetler:

Debian ailesindeki davranışları öğrenmek isteyen sistem yöneticileri Ubuntu cron job rehberimizden ilgili adımları inceleyebilir. RHEL tarafında kullanıcıların oluşturduğu crontab kayıtları doğrudan /var/spool/cron/ dizini altında kullanıcının kullanıcı adı ile saklanır. Bu dizin root:root sahipliğinde ve kısıtlı erişim izinleriyle korunur; kullanıcının bu dizine doğrudan yazma izni bulunmaz, yalnızca crontab yardımcı komutu SUID yetkisiyle bu alana güvenli kayıt yazar.

Adım Adım Kurulum ve Servis Yönetimi (cronie Paketi)

Özellikle bulut sağlayıcıların (AWS, DigitalOcean, Hetzner, Linode) sunduğu minimal Rocky Linux ve CentOS Stream kalıplarında kaynak tüketimini minimumda tutmak amacıyla cronie paketi önceden kurulu gelmeyebilir. Kurulum ve servis aktivasyonunu aşağıdaki adımlarla gerçekleştirebilirsiniz:

1. cronie Paketini Yükleyin: Terminalde root yetkisiyle veya sudo kullanarak paket yöneticisi üzerinden cronie ve anacron araçlarını sisteme dahil edin:

   sudo dnf install cronie cronie-anacron -y

2. Servisi Başlatın ve Açılışa Ekleyin: crond servisinin hem anında devreye girmesi hem de sunucu yeniden başladığında otomatik tetiklenmesi için systemctl komutunu çalıştırın:

   sudo systemctl enable --now crond

3. Servis Durumunu Doğrulayın: Daemon bileşeninin sorunsuz çalıştığını ve dinlemede olduğunu teyit edin:

   sudo systemctl status crond

4. Kullanıcı Crontab Kaydını Oluşturun: Standart kullanıcı veya root olarak düzenleyiciyi açın ve zamanlama satırını ekleyin:

   crontab -e

crond Servisinin Etkinleştirilmesi (systemctl enable --now crond)

RHEL 8 ve 9 sistemlerinde modern systemd yönetimi kullanılır. systemctl enable --now crond komutundaki --now parametresi, iki ayrı komut (enable ve start) yazma gereksinimini ortadan kaldırır. Servis durumunu sorguladığınızda Active: active (running) ifadesini görmelisiniz. Eğer servis pasif durumda ise veya başlamıyorsa sistem günlükleri journalctl -u crond.service -e komutuyla incelenmelidir.

/var/spool/cron/ Dizini ve Kullanıcı Crontab Yapısı

CentOS üzerinde bir kullanıcının zamanlanmış görevleri /var/spool/cron/kullanici_adi yolundaki metin dosyasında tutulur. Bu dosyayı asla metin düzenleyicilerle (nano, vi vb.) doğrudan düzenlememelisiniz. Doğrudan düzenleme yapıldığında crond daemon bileşeni dosyadaki inotify tetikleyicilerini kaçırabilir ve sözdizimi hatalarını yakalayamaz. Görev eklemek için mutlaka crontab sözdizimi kurallarına uygun biçimde crontab -e komutu kullanılmalıdır.

Erişim güvenliğini sağlamak için RHEL sistemlerinde iki kritik dosya bulunur: /etc/cron.allow ve /etc/cron.deny. Eğer sistemde cron.allow dosyası mevcutsa, yalnızca bu dosyada adı geçen kullanıcılar crontab komutunu çalıştırabilir. Eğer bu dosya yoksa, cron.deny dosyasına bakılır ve orada adı bulunmayan her kullanıcıya izin verilir. İki dosya da mevcut değilse dağıtım ayarlarına bağlı olarak yalnızca root kullanıcısı yetkilendirilir.

SELinux ile Cron Etkileşimi ve İzin İhlallerini Çözme

CentOS, Rocky Linux ve AlmaLinux sistemlerinde cron hataları dosya izinlerinden veya SELinux engellemelerinden kaynaklanabilir. SELinux, süreçlerin dosya sistemine erişimini "type enforcement" kurallarıyla sınırlandırır. Sistemde crond servisi crond_t context etiketi altında çalışırken, çalıştırılan betiklerin ve bu betiklerin yazdığı dizinlerin uygun SELinux güvenlik etiketine (security context) sahip olması şarttır.

Örneğin ev dizininiz olan /home/kullanici/scripts/ altına yazdığınız bir kabuk betiği genellikle user_home_t etiketi alır. Bu etiketteki bir dosyanın çalıştırılmasına izin verilip verilmediği görevin SELinux alanına ve etkin politikaya bağlıdır; yalnızca ev dizininde bulunması engellendiği anlamına gelmez. SELinux durumunu kontrol etmek için:

getenforce
# Enforcing sonucunu alıyorsanız SELinux tam koruma modundadır.

Cron kaynaklı bir engelleme şüphesi duyduğunuzda denetim loglarını sorgulayarak AVC (Access Vector Cache) ret kayıtlarını listeleyebilirsiniz:

sudo ausearch -m avc -ts recent | grep crond

Denetim kayıtları yanlış dosya bağlamını gösteriyorsa önce restorecon ile varsayılan etiketi geri yükleyin. Politikanız özel betik dizini için bin_t gerektiriyorsa aşağıdaki kalıcı eşlemeyi uygulayabilirsiniz:

# Betik dizininin etiketini kalıcı olarak cron ile uyumlu hale getirin
sudo semanage fcontext -a -t bin_t "/home/kullanici/scripts(/.*)?"
sudo restorecon -Rv /home/kullanici/scripts/

RHEL sistemlerinde cron süreçlerinin loglarını derinlemesine incelemek istediğinizde /var/log/cron dosyasını gerçek zamanlı izlemek en doğru teşhis adımıdır.

Gerçek Kod Örnekleri

Aşağıda kurumsal sunucu ortamlarında sıkça ihtiyaç duyulan pratik otomasyon betikleri yer almaktadır. Kod bloklarını kendi sunucu mimarinize göre uyarlayabilirsiniz.

Rocky Linux ve CentOS İçin Otomatik crond Kurulum ve Test Scripti

Bu Bash betiği, sistemde cronie paketinin varlığını denetler, eksikse kurar, servisi başlatır ve geçerli kullanıcı adına örnek bir test cron görevi tanımlar:

#!/usr/bin/env bash
set -euo pipefail

echo "[*] RHEL/Rocky Linux Cron Ortamı Hazırlanıyor..."

# Root yetkisi kontrolü
if [[ $EUID -ne 0 ]]; then
   echo "[!] Bu kurulum betiği root yetkileriyle çalıştırılmalıdır." >&2
   exit 1
fi

# cronie paketinin kontrolü ve kurulumu
if ! rpm -q cronie >/dev/null 2>&1; then
    echo "[+] cronie paketi bulunamadı, DNF üzerinden kuruluyor..."
    dnf install -y cronie cronie-anacron
else
    echo "[OK] cronie paketi zaten kurulu."
fi

# Servisi etkinleştir ve başlat
echo "[+] crond servisi aktifleştiriliyor..."
systemctl enable --now crond.service

# Servis çalışma kontrolü
if systemctl is-active --quiet crond; then
    echo "[OK] crond servisi başarıyla çalışıyor."
else
    echo "[!] crond servisi başlatılamadı!" >&2
    exit 1
fi

# Test görevi oluşturma (/tmp/cron_test.log içine her 10 dakikada bir tarih yazar)
CRON_JOB="*/10 * * * * date >> /tmp/cron_test.log 2>&1"
( crontab -l 2>/dev/null | grep -Fv "/tmp/cron_test.log" || true; echo "$CRON_JOB" ) | crontab -
echo "[OK] Test görevi crontab listesine eklendi."
crontab -l

SELinux İzinlerini Onaran ve Context Atayan Bakım Scripti

Özel dizinlerde tutulan betiklerin crond tarafından sorunsuz çalıştırılabilmesi için SELinux bağlamlarını denetleyen ve onaran bakım betiği:

#!/usr/bin/env bash
set -euo pipefail

TARGET_DIR="/opt/cron_scripts"

echo "[*] Hedef dizin denetleniyor: ${TARGET_DIR}"

if [[ ! -d "${TARGET_DIR}" ]]; then
    mkdir -p "${TARGET_DIR}"
    chmod 750 "${TARGET_DIR}"
fi

# Dosya izinlerini düzelt (okuma ve çalıştırma hakkı)
find "${TARGET_DIR}" -type f -name "*.sh" -exec chmod 755 {} +

# SELinux bağlamını bin_t olarak işaretle
if command -v semanage >/dev/null 2>&1; then
    echo "[+] SELinux fcontext kuralı ekleniyor..."
    semanage fcontext -a -t bin_t "${TARGET_DIR}(/.*)?" || true
    restorecon -Rv "${TARGET_DIR}"
    echo "[OK] SELinux güvenlik bağlamları güncellendi."
else
    echo "[!] semanage aracı bulunamadı (policycoreutils-python-utils paketini kurabilirsiniz)."
    echo "[+] Geçici olarak chcon uygulanıyor..."
    chcon -R -t bin_t "${TARGET_DIR}"
fi

ls -lZ "${TARGET_DIR}"

Sık Karşılaşılan Hatalar ve Çözümleri

RHEL tabanlı sistemlerde zamanlanmış görev kurulumlarında en sık karşılaşılan 4 kritik hata mesajı ve çözüm yolları şunlardır:

1. Unit crond.service could not be found

Nedeni: Özellikle konteyner ortamlarında (Docker/Podman) veya minimal ISO ile kurulmuş Rocky Linux ve CentOS Stream sanal sunucularında cronie paketi önceden yüklenmemiş olabilir. Bu durumda systemctl servisi bulamaz.
Çözümü: Sisteme paket yöneticisi ile cronie eklenmelidir: sudo dnf install cronie cronie-anacron -y && sudo systemctl enable --now crond. Detaylı sorun giderme adımları için cron job çalışmıyor rehberimizi inceleyebilirsiniz.

2. crond: can't lock /var/run/crond.pid, otherpid may be 1234

Nedeni: Başka bir crond süreci /var/run/crond.pid dosyasının kilidini tutmaktadır. Dosyanın tek başına diskte kalması bu kilit hatasını açıklamaz; süreç sonlandığında işletim sistemi kilidi bırakır.
Çözümü: Çalışan süreçleri pgrep -l crond ile kontrol edin ve elle başlatılmış ikinci crond sürecini sonlandırın. Servisi sudo systemctl restart crond ile yönetin; çalışan süreç varken PID dosyasını silmeyin.

3. You (kullanici) are not allowed to use this program (crontab)

Nedeni: Kullanıcı hesabınızın adı /etc/cron.deny dosyasında yer alıyor olabilir ya da sistemde bir /etc/cron.allow dosyası bulunmasına rağmen sizin adınız bu dosyaya eklenmemiştir.
Çözümü: Root yetkisiyle /etc/cron.deny dosyasını açıp ilgili kullanıcı adını kaldırın veya kullanıcı adınızı /etc/cron.allow içerisine yeni bir satır olarak ekleyin: echo "kullanici_adi" | sudo tee -a /etc/cron.allow.

4. type=AVC msg=audit(...): avc: denied { execute } for pid=...

Nedeni: SELinux, crond servisinin betik dosyasını çalıştırmasını güvenlik politikası gereği engellemektedir. Betik dosyası standart olmayan bir dizindedir veya yanlış güvenlik bağlamı (security context) taşımaktadır.
Çözümü: Betiğin SELinux context bilgisini ls -lZ /yol/betik.sh ile kontrol edin. Ardından sudo restorecon -v /yol/betik.sh komutuyla varsayılan bağlamı yükleyin veya doğrudan çalıştırılabilir bağlam atayın: sudo chcon -t bin_t /yol/betik.sh.

Masaüstü ve dizüstü bilgisayarlarda veya periyodik kapanan sanal makinelerde kaçırılan işlerin mantığını anlamak için anacron nedir başlıklı makalemize göz atabilirsiniz.

cronjob.com.tr ile HTTP Tabanlı Alternatif Kurulum (Firewall Dostu Dış Tetikleme)

CentOS ve Rocky Linux sunucularda yerel cronie servisini yapılandırmak; SELinux kuralları, kısıtlı ortam değişkenleri ($PATH), bellek limitleri ve crond servis kilitlenmeleri gibi operasyonel riskler barındırır. Özellikle kurumsal sunucularda güvenlik duvarları ve sıkılaştırılmış işletim sistemi politikaları yerel betiklerin yönetimini zorlaştırabilir.

Bu tür karmaşık sistem yönetimi yüklerinden kaçınmak için modern yazılım mimarilerinde HTTP tabanlı tetikleme tercih edilmektedir. Zamanlanmış görevinizi sunucu içinde bir kabuk betiği olarak tutmak yerine, web sunucunuz (Nginx/Apache) arkasında güvenli bir webhook uç noktası olarak tanımlayabilir ve bu adresi cronjob.com.tr üzerinden periyodik olarak tetikleyebilirsiniz.

Örneğin Nginx ve PHP-FPM üzerinde barınan bir CentOS sunucusunda yedekleme veya kuyruk işleme görevini şu şekilde güvenli bir uç noktaya dönüştürebilirsiniz:

<?php
// /var/www/html/api/cron-task.php
declare(strict_types=1);

// Yalnızca cronjob.com.tr tarafından iletilen gizli başlığı doğrula
$secretHeader = $_SERVER['HTTP_X_CRON_TOKEN'] ?? '';
$validToken = 'f9c8d7e6a5b4c3d2e1f0a9b8c7d6e5f4';

if (!hash_equals($validToken, $secretHeader)) {
    http_response_code(403);
    echo json_encode(['error' => 'Erişim yetkisi reddedildi.']);
    exit;
}

// Zamanlanmış iş mantığı burada yürütülür
// Örn: Veritabanı optimizasyonu, e-posta kuyruğu gönderimi
$processedCount = 142;

http_response_code(200);
echo json_encode([
    'status' => 'success',
    'processed' => $processedCount,
    'timestamp' => time()
]);

Bu yaklaşımın sunduğu temel avantajlar ve cronjob.com.tr teknik özellikleri şunlardır:

• Ücretsiz ve Kartsız Başlangıç: cronjob.com.tr tamamen ücretsizdir ve kayıt esnasında kredi kartı bilgisi talep edilmez.
• Esnek Zamanlama: 60 saniyeden başlayan hazır aralıkları seçebilir veya standart 5 alanlı cron ifadesi (dakika, saat, gün, ay, haftanın günü) tanımlayabilirsiniz. Europe/Istanbul dahil olmak üzere iş bazında özel saat dilimi belirlenebilir.
• Geniş HTTP Metot Desteği: GET, POST, PUT, PATCH, DELETE gibi metotlar kullanılabilir; yukarıdaki örnekte olduğu gibi özel HTTP başlıkları (örneğin X-Cron-Token) ve istek gövdesi gönderilebilir.
• Akıllı Yanıt Bekleme (Timeout): 1 dakikalık işlerde 55 saniye, 2 dakikalık işlerde 115 saniye, 5 dakika ve üzerindeki ya da cron ifadeli görevlerde 290 saniyeye kadar yanıt bekleme süresi tanınır.
• İzleme ve Bildirimler: HTTP 200–399 haricindeki kodlar veya bağlantı kopmaları hata sayılır. Belirlediğiniz ardışık hata eşiği (varsayılan 3) aşıldığında sistem size kesinti e-postası iletir; sorun giderildiğinde ise toplam kesinti süresini belirten düzelme bildirimi gönderilir. Aynı iş için bildirimler arasında en az 60 dakika bulunur.
• Detaylı Çalışma Günlükleri: Her tetiklemeye ait HTTP durum kodu, yanıt süresi, hata ayrıntısı ve yanıt gövdesinin ilk ~64 KB'lık kısmı 7 gün boyunca sistemde saklanır.

Sıkça Sorulan Sorular (SSS)

CentOS'ta servis adı neden cron değil de crond?

Red Hat ve RHEL tabanlı dağıtımlarda (CentOS, Rocky Linux, AlmaLinux) arka planda sürekli çalışan daemon servislerinin sonuna geleneksel olarak d harfi eklenir; bu nedenle servis adı cron değil crond veya tam adıyla crond.service olarak tanımlanmıştır.

Rocky Linux 9'da cron logları nerede tutulur?

Rocky Linux ve AlmaLinux sistemlerinde cron işlemlerine ait kayıtlar geleneksel olarak /var/log/cron dosyasında tutulur; ayrıca systemd journal kullanan sistemlerde journalctl -u crond komutuyla da anlık ve geçmiş kayıtlar incelenebilir.

CentOS Stream'de cron kurulu gelir mi?

CentOS Stream ve minimal sunucu kurulumu kalıplarında kaynak tasarrufu amacıyla cronie paketi varsayılan olarak hariç tutulabilir; bu durumlarda dnf install cronie cronie-anacron -y komutuyla elle kurulması ve servisin etkinleştirilmesi gerekir.

cronie ile anacron arasındaki fark nedir?

cronie paketi 7/24 kesintisiz çalışan sunucu ortamlarında dakikası dakikasına zamanlanmış görevleri yürütürken; anacron sistemi kapalı kalan ve açıldığında geçmişte kaçırılan günlük, haftalık ya da aylık görevleri telafi ederek çalıştıran mekanizmadır.

Sonuç

CentOS Stream, Rocky Linux ve AlmaLinux ortamlarında cron görevleri yönetirken cronie mimarisini, crond servis adını, /var/log/cron günlüklerini ve SELinux kurallarını göz önünde bulundurmak kesintisiz otomasyon için şarttır. Sistem kaynaklarını zorlamadan ve SELinux kısıtlamalarına takılmadan dış tetikleme yapmak istediğinizde cronjob.com.tr servisinden faydalanabilirsiniz.

İlgili Rehberler