Linux Sunucularda Cron Job Yönetimi: Güvenli Zamanlama ve Sorun Giderme

Son Güncelleme: Eylül 2026

Cron job (zamanlanmış görev), Linux sunucularda bakım komutlarını, veri işleme betiklerini ve uygulama görevlerini belirli aralıklarla çalıştırmanın yaygın bir yoludur. Ancak yanlış zaman ifadesi, eksik ortam değişkeni veya aynı görevin üst üste başlaması; başarısız işlemlere ve gereksiz kaynak tüketimine neden olabilir. Bu rehber, crontab yapılandırmasını güvenli biçimde hazırlamayı, görevleri izlemeyi ve sorunları sistematik olarak gidermeyi anlatır.

İçindekiler

• Cron Nedir ve Nasıl Çalışır?
• Crontab Zamanlama Söz Dizimi
• Güvenli Bir Cron Görevi Oluşturma
• Kaynak Kullanımı ve Görev Çakışmalarını Önleme
• İzleme ve Sorun Giderme
• Hosting ve Sunucu Kullanım Senaryoları
• Yayına Almadan Önce Kontrol Listesi
• Sıkça Sorulan Sorular
• Sonuç

Cron Nedir ve Nasıl Çalışır?

Cron, tanımlanan zaman çizelgesine göre komut başlatan bir görev zamanlayıcısıdır. Kullanıcıya ait görevler genellikle o kullanıcının crontab kaydında tutulur. Sistem genelindeki /etc/crontab ve /etc/cron.d/ girdilerinde ise zaman alanlarıyla komut arasına görevi çalıştıracak kullanıcı adı eklenir. Bu ayrımı gözden kaçırmak, geçerli görünen bir satırın hiç çalışmamasına yol açabilir.

Cron, bir komutu belirlenen anda başlatır; komutun başarıyla tamamlandığını, beklenen dosyayı ürettiğini veya sonucu başka bir sisteme ulaştırdığını tek başına garanti etmez. Bu nedenle bir cron görevi tasarlanırken üç ayrı soru yanıtlanmalıdır: Ne zaman başlayacak? Hangi yetkiyle çalışacak? Başarı veya hata nasıl anlaşılacak? Görev kritikse yalnızca zamanlamaya güvenmek yerine uygulama çıktısını, çıkış kodunu ve iş sonucunu da izlemek gerekir.

Kullanıcı crontab kaydı ile sistem crontab kaydı arasındaki fark

Bir uygulama kullanıcısının kendi zamanlanmış görevlerini görüntülemek için aşağıdaki komut kullanılabilir. Düzenleme komutu, o kullanıcıya ait kayıtları açar; işlem başka bir kullanıcı hesabıyla yapılıyorsa görülen kayıtlar da farklı olacaktır.

crontab -l
crontab -e

crontab -e içine yazılan bir görevde ayrıca kullanıcı adı alanı bulunmaz. Buna karşılık sistem yöneticisinin yönettiği /etc/crontab gibi dosyalarda kullanıcı alanı vardır. Aynı satırı bu iki konum arasında olduğu gibi kopyalamamak gerekir. Yönetim paneli tarafından oluşturulan görevlerde de önce panelin görevi hangi kullanıcı adına kaydettiği kontrol edilmelidir.

Crontab Zamanlama Söz Dizimi

Standart bir kullanıcı cron satırı, soldan sağa dakika, saat, ayın günü, ay, haftanın günü ve çalıştırılacak komuttan oluşur. Yıldız işareti ilgili alanın tüm geçerli değerlerini temsil eder. Aralıklar kısa çizgiyle, listeler virgülle, düzenli adımlar ise eğik çizgiyle ifade edilir.

Aşağıdaki örnekler, kullanıcı crontab kaydı içindir. İlk satır her gün 03.15'te, ikinci satır hafta içi her gün 09.00'da, üçüncü satır ise her beş dakikada bir çalışır. Örnek komutlar gösterim amaçlıdır; gerçek kullanımda komutların ve dosya yollarının sunucuda mevcut olması gerekir.

15 3 * * * /usr/bin/true
0 9 * * 1-5 /usr/bin/true
*/5 * * * * /usr/bin/true

Ayın günü ile haftanın günü birlikte kısıtlandığında yaygın cron uygulamalarında mantık beklenenin tersine dönebilir: Satır, iki koşulun aynı anda sağlandığı günlerde değil, bunlardan herhangi birinin sağlandığı günlerde çalışabilir. Örneğin ayın birinci günü ile pazartesiyi birlikte yazmak, yalnızca pazartesiye denk gelen ayın ilk gününü seçmez. Böyle bir gereksinimde tarih kontrolünü betiğin içine taşımak ve hedef sistemde test etmek daha güvenlidir.

Sunucu saat dilimi de zamanlamanın parçasıdır. Bazı cron uygulamalarında görevlerin hangi saat dilimine göre tetiklendiği ile komutun içinde kullanılan saat dilimi farklı biçimde yönetilebilir. Bu yüzden yalnızca cron kaydına bir TZ değişkeni ekleyerek tetikleme saatinin değiştiğini varsaymayın. Sunucunun saat dilimini, kullanılan cron uygulamasını ve yaz saati geçişlerini doğrulayın. Özellikle gece saatlerine yerleştirilen kritik işler, saatlerin ileri veya geri alındığı günlerde hiç başlamayabilir ya da iki kez başlayabilir.

Güvenli Bir Cron Görevi Oluşturma

İyi bir cron görevi, önce terminalde aynı kullanıcı hesabıyla çalıştırılmış ve beklenen çıktıyı üretmiş bir komuttan oluşur. Cron oturumunda etkileşimli kabuğun alışılmış ayarları bulunmayabilir; bu nedenle göreceli dosya yolları, kabuk takma adları ve yalnızca oturum açınca tanımlanan değişkenler güvenilir değildir. Komutların ve dosyaların mutlak yollarını kullanmak, sürprizleri azaltır.

Yetkileri en aza indirin

Uygulamanın kendi dosyalarını işleyecek bir görevi, gerekmediği hâlde yönetici yetkisiyle çalıştırmayın. Ayrı bir uygulama kullanıcısı, görevin erişebildiği dosyaları sınırlar. Örneklerdeki appuser hesabı ile /srv/uygulama/ ve /home/appuser/ yolları temsildir; bunları gerçek kurulumunuza göre değiştirin. Önce günlük ve kilit dosyaları için, ilgili kullanıcının yazabildiği dizinleri hazırlayın:

mkdir -p /home/appuser/logs /home/appuser/run
chmod 700 /home/appuser/logs /home/appuser/run

Bu komutlar görev sahibi kullanıcı olarak çalıştırılmalıdır. Dizinleri başka bir hesap oluşturduysa sahiplik ve yazma izni ayrıca doğrulanmalıdır. Cron kaydının okunabilir olması gereken yönetim süreçlerini de hesaba katarak parola, erişim anahtarı veya veritabanı bağlantı bilgisini doğrudan cron satırına yazmaktan kaçının. Hassas bilgiler için uygulamanın yetkileri sınırlandırılmış yapılandırma mekanizmasını kullanın.

Komutu küçük bir betikte toplayın

Birden fazla işlem yapılacaksa uzun bir cron satırı yerine ayrı bir kabuk betiği hazırlayın. Aşağıdaki örnek, görevin başladığı ve bittiği zamanı yazdırır. /srv/uygulama/bin/gorev.sh dosyasını oluşturduktan sonra gerçek uygulama komutunu belirtilen yere ekleyin; örnekteki /usr/bin/true yalnızca başarılı çıkışı gösterir ve uygulama işi yapmaz.

#!/bin/sh
set -eu
printf 'Baslangic: %s\n' "$(date -Is)"
cd /srv/uygulama
/usr/bin/true
printf 'Bitis: %s\n' "$(date -Is)"

Betiğe çalıştırma izni verip cron'a eklemeden önce aynı kullanıcıyla elle çalıştırın. set -e, basit hata durumlarında betiğin durmasına yardımcı olur; ancak her kabuk bağlamında tüm başarısızlıkları yakalayan bir güvence değildir. İşin gerçekten tamamlandığını doğrulamak için çıktı dosyası, uygulama günlüğü veya işlenen kayıt sayısı gibi sonuç göstergeleri de kontrol edilmelidir.

chmod 700 /srv/uygulama/bin/gorev.sh
/srv/uygulama/bin/gorev.sh

Dikkat: Bir komuttaki yüzde işareti, crontab komut alanında özel anlam taşıyabilir. Örneğin tarih biçimi üreten bir komutu doğrudan cron satırına koymak beklenmedik sonuç verebilir. Tarih biçimlendirmesini ayrı bir betiğe taşımak, bu sorunu önlemenin pratik yollarından biridir.

Kaynak Kullanımı ve Görev Çakışmalarını Önleme

Bir görev beş dakikada bir tetiklenirken tamamlanması yedi dakika sürüyorsa yeni kopya, eskisi çalışmayı bitirmeden başlayabilir. Bu durum veritabanı yazımlarını çakıştırabilir, aynı e-postayı iki kez gönderebilir veya CPU ve disk kullanımını artırabilir. Zaman aralığını tahmini süreden uzun tutmak yararlıdır; ancak görev süresi değişebileceği için eşzamanlı çalışmayı önleme ayrıca ele alınmalıdır.

Linux sistemlerde flock, aynı kilit dosyası için birden fazla yerel sürecin eşzamanlı çalışmasını önlemeye yardımcı olabilir. Aşağıdaki kullanıcı crontab örneğinde kilit alınamazsa yeni kopya beklemeden çıkar. Çıktı ve hata akışı günlük dosyasına eklenir. Örneği kullanmadan önce dizinlerin görev sahibi tarafından yazılabilir olduğunu ve flock aracının sistemde bulunduğunu doğrulayın.

*/5 * * * * /usr/bin/flock -n /home/appuser/run/gorev.lock /srv/uygulama/bin/gorev.sh >> /home/appuser/logs/gorev.log 2>&1

flock -n kullanıldığında kilit doluysa o zaman dilimindeki yeni deneme atlanır; daha sonra otomatik olarak sıraya alınıp çalıştırılacağını varsaymayın. Bir görevin her çalışmasının tamamlanması zorunluysa kuyruk, yeniden deneme ve tekilleştirme gereksinimlerini uygulama düzeyinde tasarlayın. Ayrıca bu tür bir dosya kilidi, ortak bir koordinasyon sistemi olmadan farklı sunucularda çalışan görevlerin birbirini engellemesini sağlamaz.

Kaynak tüketimini düşürmek için bütün görevleri gece tam saatte başlatmak yerine zamanlarını dağıtın. Örneğin raporlama 03.10'da, uygulama bakımı 03.25'te, başka bir yoğun işlem 03.40'ta başlayabilir. Yine de yalnızca başlangıç saatlerini ayırmak yeterli olmayabilir: İşlerin gerçek çalışma süreleri ve aynı diski ya da veritabanını kullanıp kullanmadıkları izlenmelidir.

İzleme ve Sorun Giderme

Bir cron satırı çalışmıyor gibi görünüyorsa önce görev tanımının doğru kullanıcıya ait olup olmadığını kontrol edin. Ardından zaman ifadesini, dosya yollarını, betiğin çalıştırma iznini ve günlük çıktısını inceleyin. Sorunu bulmanın en hızlı yollarından biri, cron'daki komutu görev sahibi kullanıcı olarak terminalde çalıştırmaktır. Elle çalıştırma başarılı olsa bile cron'un daha sınırlı ortamı nedeniyle ayrıca ortam değişkenlerini incelemek gerekebilir.

crontab -l
ls -l /srv/uygulama/bin/gorev.sh
tail -n 50 /home/appuser/logs/gorev.log

Görev kayıtlarının nerede tutulduğu dağıtıma ve günlük yapılandırmasına göre değişir. Hizmetin etkinliğini denetlerken bazı sistemlerde hizmet adının cron, bazılarında crond olabileceğini unutmayın. Aşağıdaki komutlardan sisteminize uygun olanı kullanın; hata çıktısı görürseniz hizmetin gerçekten hangi adla kurulu olduğunu inceleyin.

systemctl status cron
systemctl status crond

Komutun stdout (standart çıktı) ve stderr (standart hata çıktısı) akışlarını günlük dosyasına yönlendirmek, özellikle ilk kurulumda yararlıdır. Ancak günlük dosyasını süresiz büyütmek disk alanını tüketebilir. Saklama süresi, döndürme yöntemi ve hassas bilgilerin günlüğe yazılıp yazılmadığı ayrıca planlanmalıdır. Çıktıyı tamamen susturmak, bir görevin başarısızlığını fark etmeyi zorlaştırabilir.

Görev başladı ama sonuç oluşmadıysa

Bu durumda sorun zamanlayıcıdan çok uygulama komutunda olabilir. Veritabanına erişim, ağ bağımlılıkları, çalışma dizini ve hedef dosya izinlerini denetleyin. Bir işin yalnızca başlangıç kaydı görülüyor, bitiş kaydı görünmüyorsa komut hata vermiş, takılmış veya sistem tarafından sonlandırılmış olabilir. Betiklerin makul sürede tamamlanmasını sağlayın; uzun işlerde uygulamaya uygun bir süre sınırı ve kontrollü yeniden deneme yaklaşımı belirleyin.

Özellikle birden fazla sunucunun aynı uygulamayı barındırdığı yapılarda, cron kaydının her makinede bulunup bulunmadığını kontrol edin. Aynı faturalama veya bildirim işinin iki sunucuda birden çalışması, yerel günlüklerde her iki çalıştırma da başarılı görünse bile yanlış iş sonucuna yol açabilir. Böyle durumlarda görevin tek bir yerde yürütülmesi ya da dağıtık düzeyde koordinasyon sağlanması gerekir.

Hosting ve Sunucu Kullanım Senaryoları

Web sitesi bakımı: Önceden oluşturulmuş geçici dosyaların temizlenmesi veya uygulamanın ürettiği bir dizinin kontrolü zamanlanabilir. Temizlik betiği yalnızca açıkça belirlenmiş uygulama dizininde işlem yapmalı; silme koşulları üretim ortamında önce güvenli örnekler üzerinde denenmelidir. Genel bir geçici dizini gelişigüzel boşaltmak başka hizmetlerin dosyalarına zarar verebilir.

E-ticaret veri akışı: Stok veya fiyat verisi belirli aralıklarla içe aktarılabilir. Burada önemli olan yalnızca görevi sık çalıştırmak değildir. Bir içe aktarma devam ederken yenisinin başlamaması, aynı kaydın iki kez işlenmemesi ve başarısız partinin tespit edilebilmesi gerekir. Kilit mekanizması ile uygulama düzeyindeki kayıt tekilleştirme birlikte değerlendirilebilir.

Raporlama: Günlük raporlar trafik yoğunluğunun düşük olduğu saatlere alınabilir. Ancak rapor zamanının sunucu saat dilimine mi, işletmenin yerel saatine mi göre belirlendiği açık olmalıdır. Ay kapanışı gibi takvim hassasiyeti olan işlerde yaz saati değişimi ve ayın farklı uzunlukları ayrıca test edilmelidir.

Yedekleme doğrulaması: Zamanlanmış bir görev, yedek dosyasının beklenen zamanda oluşup oluşmadığını ve temel bütünlük kontrollerini denetleyebilir. Bununla birlikte dosyanın varlığı, geri yüklenebilir olduğunu kanıtlamaz. Ayrı bir geri yükleme testi ve bağımsız saklama politikası gerekir. Kritik yedeklerin yalnızca cron kaydına bırakılması, izleme olmadan sessiz başarısızlık riski taşır.

Hosting paneli kullanımı: Panelin cron arayüzü, teknik olmayan ekiplerin görevleri görmesini kolaylaştırabilir. Buna rağmen panelde seçilen kullanıcı, kullanılan PHP yorumlayıcısı ve komutun çalışma dizini yine doğrulanmalıdır. Paylaşımlı hosting ortamında işletim sistemi düzeyindeki her komuta erişim bulunmayabilir; uzun süreli veya kaynak yoğun işler için erişim ve kapasite koşulları önceden değerlendirilmelidir.

Yayına Almadan Önce Kontrol Listesi

Aşağıdaki kısa liste, üretim ortamına alınacak bir zamanlanmış görevin hem teknik hem de operasyonel yönünü kontrol etmeye yardımcı olur:

• Görev sahibi: Komut, ihtiyaç duyduğu en düşük yetkiye sahip kullanıcıyla çalışıyor mu?
• Zaman ifadesi: Saat dilimi, hafta günü ve ayın günü koşulları beklenen takvime uyuyor mu?
• Dosya yolları: Betik, yorumlayıcı, günlük ve kilit dosyaları için geçerli mutlak yollar kullanılıyor mu?
• Elle test: Aynı komut, görev sahibi kullanıcıyla etkileşimsiz koşullara yakın biçimde test edildi mi?
• Çakışma kontrolü: Önceki çalışma bitmeden yenisi başlarsa ne olacağı belirlendi mi?
• Sonuç doğrulama: Başarısız görevleri ve yanlış iş sonuçlarını fark edecek bir izleme yöntemi var mı?
• Günlük yönetimi: Günlüklerin boyutu, erişim izinleri ve saklama süresi planlandı mı?
• Değişiklik kaydı: Görevin amacı, sahibi ve son değişiklik bilgisi ekip içinde belgeleniyor mu?

Kontrol listesindeki her madde, farklı bir hata sınıfını azaltır. Örneğin doğru zaman ifadesi izin hatasını çözmez; başarılı çıkış kodu da yanlış verinin işlenmediğini kanıtlamaz. Kritik görevlerde devreye alma sonrasında ilk birkaç çalıştırmayı gözlemlemek ve elde edilen iş sonucunu doğrulamak iyi bir son adımdır.

Sıkça Sorulan Sorular

Sonuç

Güvenilir cron yönetimi, beş alanlı bir zaman ifadesi yazmaktan daha fazlasıdır. Doğru kullanıcı yetkisi, mutlak yollar, çakışma kontrolü, günlükleme ve iş sonucunun izlenmesi birlikte ele alındığında zamanlanmış görevler daha öngörülebilir hâle gelir. Önce komutu elle doğrulayın, ardından gerçek ortamda ilk çalışmaları gözlemleyin ve kritik işler için hata durumunda uygulanacak adımları belgeleyin.

Zamanlanmış uygulama işlerininiz için ortam seçerken erişim düzeyi ve kaynak gereksinimlerinizi değerlendirebilirsiniz. Corelux Linux Hosting, Sanal Sunucu ve Kiralık Sunucu seçeneklerini iş yükünüzün yönetim ve kapasite ihtiyaçları açısından inceleyin. Kritik veriler için zamanlanmış işlemleri, uygun bir Yedekleme Hizmeti ve düzenli geri yükleme testleriyle destekleyin.