Cron Nedir? Linux Cron Daemon (crond) Rehberi

Cron, Linux üzerinde belirli zamanlarda komut başlatan arka plan servisidir; sürekli çalışan bu tür süreçlere daemon denir. Programın adı sisteminizde cron veya crond olabilir. Bir görev saati geldiği halde başlamıyorsa yalnızca zaman ifadesini değiştirmek yetmez: servisin çalışması, doğru dosyayı okuması ve komutu uygun hesapla başlatması gerekir.

Bu rehberde cron daemon mimarisini, dağıtımlar arasındaki farkları ve servis düzeyinde teşhis yöntemini öğreneceksiniz. Komutları Linux sunucunuzda uygulayın; systemctl örnekleri systemd kullanan makineler içindir. Zaman alanlarının ayrıntıları için crontab sözdizimi referansına, kullanıcı tablolarını yönetmek için crontab komutları rehberine geçebilirsiniz. Kavramın genel tanımını ve Windows gibi diğer işletim sistemlerindeki karşılıklarını zamanlanmış görev nedir rehberinde bulabilirsiniz.

Cron daemon nasıl çalışır?

Daemon görev tanımlarını okur, zamanlamaları bellekte tutar ve dakika bazında hangi komutların başlaması gerektiğini değerlendirir. Eşleşen işi ilgili hesabın yetkileriyle bir alt süreçte başlatır. Servis yöneticisi daemonu çalıştırırken crontab komutu kullanıcının görev tablosunu yönetir. Bunlar farklı sorumluluklardır; bir crontab dosyasının bulunması servisin açık olduğunu göstermez.

Cronie ve Debian cron dosya değişikliklerini izleyerek tanımları yeniden okur. Normal bir tablo düzenlemesinden sonra servisi yeniden başlatmanız gerekmez. Kullanıcı tablolarını spool dizinine elle kopyalamak yerine crontab komutuyla kurun. Dosya okunmuş olsa bile uygulamanın iş sonucunu ayrıca denetleyin: zamanlayıcının komutu başlatması raporun üretildiği anlamına gelmez.

Zamanı gelen işler birbirinden bağımsız başlatılabilir. Cron önceki çalışmanın bitmesini bekleyen bir kuyruk değildir. Uzun süren görevlerde kilit veya uygulama düzeyinde eşzamanlılık kontrolü planlayın. Başarı kontrolünüz yalnızca süreç kaydına değil, işin ürettiği dosyaya veya uygulamanın sonuç kaydına da dayanmalıdır.

Vixie Cron, Cronie ve BusyBox crond farkları

Bu uygulamaların bütün seçeneklerinin aynı olduğunu varsaymayın. Bir Cronie komutundaki bayrak BusyBox üzerinde bulunmayabilir. Minimal konteynerde systemd de olmayabilir. Kurulu paketi ve çalışan sürecin komut satırını inceleyerek başlayın. BusyBox crond belgesi ön planda çalışma için -f, görev dizini için -c seçeneklerini açıklar. Dizin yolunu imajınızın yapılandırmasına göre seçin.

Adım adım servis durumunu doğrulama

1. Makine ve hesabı doğrulayın. SSH bağlantısının işin tanımlandığı sunucuya açıldığını kontrol edin. Yerel bilgisayarınızdaki crontab uzak sunucuyu yönetmez. hostname ve id çıktıları başlangıç için yararlıdır.
2. Doğru servis adını bulun. Debian/Ubuntu kurulumlarında cron, RHEL/Cronie düzeninde crond birimini inceleyin. Her ikisini birden başlatmak yerine mevcut paketin birimini seçin.
3. Çalışma ve açılış durumlarını ayırın. Active durumu servisin şimdi çalıştığını, enabled durumu açılışta başlatılacağını anlatır. Biri diğerinin garantisi değildir.
4. Gerekirse servisi başlatın. Kapalı bir servisi başlatmak mevcut görevleri de etkinleştirir. Bu sunucuda çalışması gereken işleri kontrol ettikten sonra uygun birime start uygulayın ve logları izleyin.

hostname
id
# Debian/Ubuntu
systemctl status cron
systemctl is-enabled cron
# RHEL ailesinde yukarıdaki birim yerine
systemctl status crond
systemctl is-enabled crond
# Yalnızca uygun birim için, gerekirse
sudo systemctl start cron

Servisten kabuğa kadar olan yolu sınamak için kendi crontab tablonuza aşağıdaki geçici satırı ekleyebilirsiniz. Birkaç dakika sonra ev dizininizdeki dosyayı okuyun ve deneme satırını kaldırın. Tarih kaydı oluşuyorsa zamanlayıcı bu basit komutu başlatmıştır; bu test gerçek uygulamanın veritabanı bağlantısını veya dosya izinlerini doğrulamaz.

* * * * * /usr/bin/date >> "$HOME/cron-deneme.log" 2>&1

/etc/crontab, /etc/cron.d ve run-parts ilişkisi

/etc/crontab sistem tablosudur. Debian cron ve Cronie kurulumlarında /etc/cron.d altındaki ek tanımlar da sistem biçimini kullanır: beş zaman alanından sonra çalıştıracak kullanıcı yazılır. Kullanıcı crontab tablosunda bu alan bulunmaz. Sistem tanımları root tarafından yönetilmeli ve başka hesaplarca yazılabilir olmamalıdır.

# /etc/cron.d/uygulama-rapor içeriği
SHELL=/bin/sh
PATH=/usr/bin:/bin
15 3 * * * rapor /usr/local/bin/rapor-uret

Örnekteki rapor hesabının ve betiğin mevcut olması gerekir; bunları kendi sunucunuza uyarlayın. Bu tanım dosyasına çalıştırma izni vermeniz gerekmez, daemon içindeki satırları ayrıştırır. Buna karşılık cron.daily içindeki dosya genellikle doğrudan çalıştırılacak bir betiktir. İki dizine aynı içerik kopyalanmaz.

cron.hourly, cron.daily, cron.weekly ve cron.monthly dizinlerinin adları kendiliğinden tetikleme yapmaz. Bunları çağıran sistem görevi veya anacron düzeni bulunmalıdır. Debian yapılandırmasında run-parts uygun betikleri seçer. run-parts belgesindeki varsayılan adlandırma kuralında noktalı adlar seçilmez; temizlik.sh yerine temizlik adı gerekebilir. Test seçeneği betikleri çalıştırmadan seçilecek dosyaları gösterir.

run-parts --test /etc/cron.daily

Cron ortamı: PATH, SHELL ve MAILTO

Terminalinizdeki takma adlar, etkin Python sanal ortamı ve kabuk başlangıç dosyaları göreve otomatik taşınmaz. PATH komut arama dizinlerini, SHELL satırı yorumlayan kabuğu belirler. Programın tam yolunu yazın; göreli dosya kullanan betiklerde çalışma dizinini açıkça seçin. Değişken atamalarında terminaldeki genişletmenin aynısını beklemeyin; PATH değerini tam olarak belirtin.

SHELL=/bin/sh
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=yonetici@example.com
0 4 * * * cd /srv/uygulama && /usr/bin/python3 rapor.py >> /srv/uygulama/rapor.log 2>&1

Bu kullanıcı tablosu örneğinde uygulama dizini ve log dosyası görev hesabına uygun izinlerle hazırlanmalıdır. Bash özelliği kullanan betiğe uygun yorumlayıcı ekleyin. MAILTO çıktının posta alıcısını belirtir; teslim için çalışan bir posta aktarım düzeni gerekir. Boş değer posta gönderimini kapatır. Cron kendiliğinden harici posta hesabınıza giriş yapmaz; üretimde yalnızca postaya güvenmeyip kalıcı çıktı kaydı tutun.

Loglama ve dört yaygın hata

Önce daemon kaydını, sonra uygulama çıktısını inceleyin. systemd journal servis başlangıç hatalarını gösterebilir. Syslog yapılandırılmışsa Debian/Ubuntu sistemlerinde /var/log/syslog, RHEL ailesinde /var/log/cron kullanılabilir; bunların her makinede bulunduğunu varsaymayın. Ayrıntılı çıktı takibi için cron loglama rehberine bakın. Bir CMD kaydı komutun başlatıldığını gösterir; uygulamanın başarılı tamamlandığını ayrıca doğrulamalısınız.

sudo journalctl -u cron --since "1 hour ago"
# Cronie birimi için
sudo journalctl -u crond --since "1 hour ago"
# Syslog dosyası bulunan Debian sisteminde
sudo grep CRON /var/log/syslog

Unit cron.service could not be found.

Yanlış servis adı veya kurulu olmayan paket bu mesajı doğurabilir. Önce crond birimini ve kurulu paketleri kontrol edin. Minimal konteynerde servis yöneticisi yoksa systemctl yerine imajın süreç başlatma düzenini inceleyin. Bu mesaj tek başına crontab satırının hatalı olduğunu göstermez.

/bin/sh: 1: php: not found

Kabuk PHP yürütücüsünü PATH içinde bulamamıştır. Görev hesabıyla komutun yolunu bulun, PHP CLI kurulumunu doğrulayın ve satırda tam yolu kullanın. Web sunucusunda PHP sayfasının açılması aynı makinede kullanılabilir CLI yürütücüsü olduğunu kanıtlamaz.

Permission denied

Betik çalıştırma, üst dizinlere erişim veya loga yazma izni eksik olabilir. Hangi yola erişimin reddedildiğini bulun ve aynı hesapla elle deneyin. Herkese yazma izni vermek yerine ilgili hesabın gereken iznini düzeltin; SELinux etkinse ret kayıtlarını da inceleyin.

Günlük dizindeki betik başlamıyor

run-parts adlandırma filtresi, çalıştırma izni veya dizini çağıran görevin eksikliği söz konusu olabilir. Önce test çıktısında betiğin seçildiğini görün. Sonra betik başındaki yorumlayıcı satırını ve sistem zamanlamasını inceleyin. Dosyanın yalnızca dizinde bulunması çalışacağı anlamına gelmez.

İki senaryo ve anacron ile kaçırılan çalışmalar

Sürekli açık sunucu: Gece 03:15 raporunu sistem tanımıyla rapor hesabında başlatabilirsiniz. Sabit saat, raporun veri kapanışından sonra üretilmesini sağlar. Önce betiği elle çalıştırıp sonuç dosyasını kontrol edin. Sunucu o saatte kapalıysa klasik cron bu çalışmayı açılışta otomatik telafi etmez; rapor uygulamasının eksik dönemi algılaması gerekebilir.

Aralıklı açılan bakım bilgisayarı: Günlük bakımın tam bir saatte değil, makine kullanılabilir olduğunda yapılması gerekiyorsa anacron uygundur. Son çalışma tarihini kaydederek gün bazındaki periyotları değerlendirir; kaçırılan her dakika için ayrı iş üretmez. Nasıl başlatıldığı dağıtımın servis düzenine bağlıdır. Aynı bakımı hem bağımsız cron satırına hem anacron tablosuna ekleyerek iki kez tetiklemeyin.

Anacron belgesi periyot ve tarih kaydı modelini açıklar. Kurulum için anacron rehberini, servis bağımlılığı ve açılış sonrası telafi seçenekleri için systemd timer karşılaştırmasını inceleyin. Daemon'ın dosya izleme ve başlatma davranışlarını Cronie crond belgesinden kontrol edebilirsiniz. Cron dışındaki zamanlayıcıların tamamını cron alternatifleri karşılaştırmasında tek tabloda görebilirsiniz.

cronjob.com.tr ile HTTP tabanlı alternatif

İş yalnızca sunucunun dosya sisteminde çalışabiliyorsa yerel daemon kullanın. Uygulamanız işi HTTPS isteğiyle güvenli biçimde başlatabiliyorsa cronjob.com.tr panelinden tetikleyebilirsiniz. Örneğin https://example.com/internal/rapor uç noktası POST kabul etsin ve uygulama gizli değeri X-Cron-Token header'ından doğrulasın. Eşleşme yoksa işi başlatmadan 401 veya 403 dönün; token'ı URL'ye veya loga yazmayın.

1. Panelde URL'yi ve POST metodunu girin.
2. Özel header alanına X-Cron-Token adını ve uygulamada saklanan gizli değeri ekleyin.
3. Günlük 03:15 için 15 3 * * * yazın, işin saat dilimini seçin; varsayılan Europe/Istanbul değerini kontrol edin.
4. Manuel çalıştırıp HTTP sonucunu ve üretilen raporu ayrı ayrı doğrulayın.

Cron ifadeli işlerde yanıt bekleme süresi 290 saniyedir. Uzun işi uygulama kuyruğuna aktarırsanız HTTP başarısı yalnızca kabulü gösterebilir. Başarı ölçütü bağlantı hatası olmadan HTTP 200–399 yanıtıdır. Ardışık hata eşiği varsayılan 3 olup 1–20 arasında ayarlanır; eşik aşılınca erişim sorunu, düzelince kesinti süresiyle düzeldi e-postası gönderilir. Aynı işte bildirimler arasında en az 60 dakika bulunur.

Sıkça Sorulan Sorular (SSS)

Cron ve crond ayrı zamanlayıcılar mı?

Bu adlar uygulamaya göre daemon'ın program veya servis adını belirtir. Kurulu paketi ve çalışan servis birimini kontrol ederek doğru adı seçin.

Crontab değişince cron servisi yeniden başlatılır mı?

Debian cron ve Cronie normal dosya değişikliklerini izler; crontab komutuyla kurulan tablo için genellikle yeniden başlatma gerekmez. Sonucu log ve deneme göreviyle doğrulayın.

Cron kapalıyken kaçırılan görevler sonradan çalışır mı?

Klasik cron kapalı kaldığı dönemin görevlerini genel olarak açılışta telafi etmez. Gün bazında telafi gereken bakım işleri için anacron düzenini değerlendirin.

Daemon root çalışıyorsa bütün işler root yetkisi mi alır?

Hayır. Kullanıcı tablosundaki iş o hesabın, sistem tablosundaki iş kullanıcı alanında belirtilen hesabın yetkileriyle çalışır. Daemon'ın yetkisi ile görevin yetkisi farklıdır.

İlgili Rehberler