logrotate ile Log Döndürme ve Temizleme

Bir sunucuda gece yarısı çalan alarmların en sinsi sebeplerinden biri, dolan disktir. Uygulama çöker, veritabanı yazma hatası verir, web sunucusu 500 döndürmeye başlar; siz de panikle df -h yazdığınızda kök bölümün yüzde 100 dolu olduğunu görürsünüz. Suçlu çoğu zaman bir güvenlik açığı ya da beklenmedik bir trafik patlaması değil, aylardır büyümeye devam eden ve kimsenin dokunmadığı bir access.log ya da application.log dosyasıdır. Loglar sunucunun hafızasıdır ama denetimsiz bırakıldığında hafıza değil, bir hastalığa dönüşür.

İşte tam bu noktada logrotate devreye girer. logrotate, log dosyalarını belirli aralıklarla ya da belirli bir boyuta ulaştığında otomatik olarak "döndüren", eskilerini sıkıştırıp arşivleyen ve makul bir süre sonra tamamen silen bir yardımcı programdır. Neredeyse her modern Linux dağıtımında hazır kurulu gelir ve arka planda sessizce çalışarak diskinizin log yüzünden dolmasını engeller. Bu rehberde logrotate'in çalışma mantığını, yapılandırma dizinlerinin düzenini, en çok kullanılan direktifleri, kendi uygulamanız için sıfırdan bir yapılandırma yazmayı ve logrotate -d ile bunu güvenle test etmeyi uygulamalı örneklerle ele alacağız.

logrotate Nedir ve Neden Gerekmez Denmez?#

logrotate, tek başına sürekli çalışan bir servis değildir; aksine belirli aralıklarla tetiklenen ve tetiklendiğinde yapılandırma dosyalarınızı okuyup gerekli döndürme işlemlerini yapan bir komut satırı aracıdır. "Döndürme" (rotation) kelimesi burada anahtar kavramdır. Döndürme, aktif log dosyasını yeniden adlandırıp yerine boş bir dosya açmak, böylece uygulamanın kesintisiz log yazmaya devam etmesini sağlarken eski kayıtları arşive taşımak demektir. Örneğin nginx/access.log dosyası döndüğünde access.log.1 olur, bir sonraki turda access.log.2 olarak kayar, en eskisi ise belirlediğiniz sınıra ulaşınca silinir.

Peki neden buna ihtiyaç duyarız? Çünkü loglar hiç durmadan büyür ve büyüdükçe iki soruna yol açar. Birincisi disk doludur: yoğun bir sitenin erişim logu günde yüzlerce megabayt, hatta gigabaytlarca yer kaplayabilir. İkincisi ise okunabilirlik kaybıdır; 8 GB'lık tek bir log dosyasında grep çalıştırmak dakikalar sürer ve dünkü bir hatayı bulmak eziyete dönüşür. logrotate her ikisini de çözer: dosyaları küçük parçalara böler, eskileri sıkıştırıp yerden kazandırır ve tanımladığınız saklama süresinin ötesindekileri otomatik temizler. Bu yüzden logrotate, kurulup unutulan ama sunucu sağlığı için kritik olan sessiz kahramanlardan biridir.

logrotate Nasıl ve Ne Zaman Çalışır?#

logrotate'in kendisi bir daemon değildir, bu nedenle "ne zaman çalışacağını" başka bir zamanlayıcı belirler. Çoğu Debian ve Ubuntu sisteminde bu iş /etc/cron.daily/logrotate betiği üzerinden cron tarafından yürütülür; yani logrotate günde bir kez, genellikle gece yarısı civarında çalışır. Zamanlanmış görevlerin nasıl işlediğini merak ediyorsanız Linux'ta cron ile zamanlanmış görevler rehberimiz konuyu ayrıntısıyla ele alıyor.

Daha yeni dağıtımlarda ise cron yerine bir systemd timer kullanılır. Bunu şu komutla doğrulayabilirsiniz:

systemctl list-timers logrotate.timer
systemctl status logrotate.timer

Bu ayrım önemlidir çünkü zamanlamayı değiştirmek istediğinizde doğru yeri düzenlemeniz gerekir. systemd timer'ları ve servis mantığı hakkında daha derin bir anlayış için systemd ile servis yönetimi yazımıza bakabilirsiniz.

Burada dikkat edilmesi gereken kritik bir nokta var: logrotate günde yalnızca bir kez tetiklendiği için, bir yapılandırmaya daily yazmanız o dosyanın "her gün" değil, "logrotate her çalıştığında ve son döndürmenin üstünden bir gün geçmişse" döndürüleceği anlamına gelir. logrotate son çalıştırma zamanlarını /var/lib/logrotate/status (bazı sistemlerde /var/lib/logrotate.status) dosyasında tutar ve her tetiklenişte bu duruma bakarak hangi logların gerçekten döndürülmesi gerektiğine karar verir. Yani zamanlayıcı ne kadar sık çalışırsa çalışsın, weekly tanımlı bir log haftada bir kez döner.

/etc/logrotate.conf ve /etc/logrotate.d Dizini#

logrotate'in yapılandırması iki katmanlıdır. Ana dosya /etc/logrotate.conf sistemin genel varsayılanlarını tutar: dosyaların ne sıklıkta döneceği, kaç kopya saklanacağı, sıkıştırmanın açık olup olmadığı gibi. Bu dosyanın sonunda neredeyse her zaman şu satır bulunur:

include /etc/logrotate.d

Bu satır sayesinde /etc/logrotate.d/ dizinindeki her dosya ana yapılandırmaya dahil edilir. İşte asıl güç buradadır: sistemdeki paketler (nginx, apache2, mysql, rsyslog) kurulduğunda kendi log kurallarını bu dizine bir dosya olarak bırakır. Sizin de yeni bir uygulama için yapmanız gereken, ana logrotate.conf dosyasına dokunmadan, /etc/logrotate.d/ altında yeni bir dosya oluşturmaktır. Bu yaklaşım hem düzenlidir hem de sistem güncellemelerinde ana dosyanın üzerine yazılması riskini ortadan kaldırır.

Tipik bir /etc/logrotate.conf dosyasının başı şöyle görünür:

# haftalık döndürme varsayılanı
weekly

# döndürülmüş logların sahibi ve grubu
su root syslog

# 4 eski kopyayı sakla
rotate 4

# döndürme sonrası boş yeni log dosyası oluştur
create

# eski logları sıkıştır
compress

# paket bazlı kurallar buradan yüklenir
include /etc/logrotate.d

Bir dizindeki dosyayı listelemek, mevcut kuralları anlamak için iyi bir başlangıçtır:

ls -l /etc/logrotate.d/
cat /etc/logrotate.d/nginx

En Çok Kullanılan Direktifler#

logrotate'in davranışını kontrol eden onlarca direktif vardır ama günlük hayatta bir avuç tanesi işinizi görür. Aşağıdaki tablo en sık kullandığınız direktifleri ve ne işe yaradıklarını özetliyor.

Birkaç direktif ekstra açıklamayı hak ediyor. compress ile delaycompress çoğu zaman birlikte kullanılır. Sadece compress açıkken bir log döndüğü anda sıkıştırılır; fakat bazı uygulamalar döndürülen dosyaya hâlâ birkaç saniye yazmaya devam edebilir ve bu da sıkıştırma sırasında veri kaybına yol açabilir. delaycompress, en son döndürülen dosyayı bir sonraki tura kadar sıkıştırmadan bırakarak bu riski ortadan kaldırır.

copytruncate ise farklı bir felsefeye dayanır. Normalde logrotate dosyayı yeniden adlandırıp yerine yenisini açar, ama bunun için uygulamanın yeni dosyayı açması (genellikle bir sinyalle yeniden yükleme) gerekir. Uygulamanız log dosyasının handle'ını bırakmıyorsa copytruncate devreye girer: dosyanın içeriğini bir kopyaya alır ve orijinal dosyayı yerinde sıfırlar. Böylece uygulamanın açık tuttuğu handle geçerli kalır. Küçük bir yarış koşulu (rotate anında yazılan birkaç satır kaybolabilir) riski taşısa da, yeniden yükleme sinyalini desteklemeyen yazılımlar için pratik bir çözümdür.

Özel Bir Uygulama Logu İçin Yapılandırma Yazmak#

Şimdi teoriyi pratiğe dökelim. Diyelim ki Node.js ile yazılmış bir uygulamanız /var/www/app/logs/ dizinine app.log ve error.log adında iki dosyaya log yazıyor. Uygulama www-data kullanıcısıyla çalışıyor ve loglar hızla büyüyor. Bu logları günlük döndürmek, 14 gün saklamak, sıkıştırmak ve döndürme sonrası uygulamaya haber vermek istiyoruz.

Öncelikle /etc/logrotate.d/app adında yeni bir dosya oluşturun:

sudo nano /etc/logrotate.d/app

İçeriğini şöyle yazın:

/var/www/app/logs/*.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    dateext
    create 0640 www-data www-data
    sharedscripts
    postrotate
        systemctl reload app.service > /dev/null 2>&1 || true
    endscript
}

Bu bloğu satır satır okuyalım. İlk satırdaki yol deseni (*.log) o dizindeki tüm .log dosyalarını kapsar. daily günlük döndürür, rotate 14 en fazla 14 eski kopyayı tutar (yani yaklaşık iki haftalık geçmiş). missingok dosya bir gün oluşmamışsa hata basmaz; notifempty boş logu boşuna döndürmez. compress ve delaycompress beraber çalışarak eski logları güvenle sıkıştırır. dateext sayesinde arşiv adları app.log-20260710.gz gibi okunabilir olur. create 0640 www-data www-data yeni boş dosyayı doğru izin ve sahiple açar ki uygulama yazmaya devam edebilsin.

sharedscripts direktifi kritiktir: desen birden fazla dosyayla eşleştiğinde (burada app.log ve error.log) postrotate bloğunu her dosya için değil, tümü döndükten sonra bir kez çalıştırır. Bu olmadan servisi iki kez yeniden yüklemeye çalışırdınız. postrotate bloğu içindeki komut ise döndürme bittikten sonra uygulamayı nazikçe yeniden yükleyerek yeni log dosyasına geçmesini sağlar; sonundaki || true servis o an yoksa logrotate'in hata vermesini engeller.

İzin ve sahiplik konusuna dikkat edin. create satırındaki kullanıcı ve grup, uygulamanızın çalıştığı kullanıcıyla uyumlu olmalıdır; aksi halde döndürme sonrası uygulama yeni dosyaya yazamaz ve sessizce log kaybedersiniz.

Yapılandırmayı Test Etmek: logrotate -d ve Zorla Çalıştırma#

Yeni bir yapılandırma yazdıktan sonra onu gerçek loglar üzerinde denemeden önce mutlaka test etmelisiniz. logrotate'in bunun için iki değerli bayrağı vardır. Birincisi -d (debug) bayrağıdır ve hiçbir şeyi gerçekten değiştirmeden, ne yapacağını ekrana yazar:

sudo logrotate -d /etc/logrotate.d/app

Bu komutun çıktısı size hangi dosyaların ele alındığını, döndürme koşullarının sağlanıp sağlanmadığını ve varsa sözdizimi hatalarını gösterir. Örnek bir çıktı parçası şuna benzer:

reading config file /etc/logrotate.d/app
Handling 1 logs

rotating pattern: /var/www/app/logs/*.log  after 1 days (14 rotations)
empty log files are not rotated, old logs are removed
considering log /var/www/app/logs/app.log
  Now: 2026-07-10 03:00
  Last rotated at 2026-07-09 03:00
  log does not need rotating (log has already been rotated)

-d bayrağı otomatik olarak ayrıntılı mod açtığı için, döndürme mantığını takip etmek çok kolaydır. Sözdizimi hatası varsa logrotate genellikle hangi satırda takıldığını da belirtir, böylece düzeltmeniz saniyeler sürer.

İkinci adım, yapılandırmanın gerçekten çalıştığını görmek için zorla döndürmedir. Normalde logrotate zaman koşulu sağlanmadan döndürme yapmaz, ama -f (force) bayrağı bu koşulu görmezden gelir:

# önce sadece göster, sonra zorla çalıştır
sudo logrotate -vf /etc/logrotate.d/app

Buradaki -v (verbose) bayrağı yapılan her işlemi anlatır, -f ise koşulu beklemeden döndürmeyi zorlar. Çalıştırdıktan sonra dizini kontrol edin:

ls -l /var/www/app/logs/

Yeni bir boş app.log, bir de app.log-20260710 (veya .gz uzantılı sıkıştırılmış) dosya görüyorsanız yapılandırmanız çalışıyor demektir. Test sırasında status dosyasını kirletmemek isterseniz --state bayrağıyla geçici bir durum dosyası kullanabilirsiniz:

sudo logrotate -vf --state /tmp/logrotate-test.state /etc/logrotate.d/app

Bu yaklaşım, gerçek /var/lib/logrotate/status dosyasına dokunmadan güvenle deneme yapmanızı sağlar.

postrotate, prerotate ve Servisleri Yeniden Yükleme#

Döndürme mekanizmasının en çok gözden kaçan ama en çok soruna yol açan yönü, uygulamanın döndürmeden haberdar edilmesidir. Klasik yeniden adlandırma yönteminde logrotate eski dosyayı taşır ve yeni boş bir dosya açar; ancak uygulama hâlâ eski (taşınmış) dosyanın açık handle'ına yazmaya devam eder. Sonuç: yeni access.log boş kalır, tüm loglar görünmez olan access.log.1 dosyasına akmaya devam eder ve disk hiç boşalmaz.

Bu sorunu çözmenin iki yolu vardır. Birincisi, döndürme sonrası uygulamaya bir sinyal göndererek log dosyasını yeniden açmasını istemektir; bunu postrotate ... endscript bloğu yapar. Nginx için tipik yapılandırma şöyledir:

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

Nginx'e gönderilen USR1 sinyali, sunucuyu durdurmadan log dosyalarını yeniden açmasını söyler; kesinti olmaz. prerotate bloğu ise adından anlaşılacağı gibi döndürmeden önce çalışır ve daha nadir kullanılır (örneğin döndürme öncesi bir uygulama arabelleğini diske boşaltmak için).

İkinci yol ise, uygulamanız sinyal desteklemiyorsa daha önce bahsettiğimiz copytruncate yöntemidir:

/var/www/legacy-app/logs/output.log {
    daily
    rotate 7
    compress
    delaycompress
    copytruncate
    missingok
    notifempty
}

İki yaklaşımı kıyaslayalım:

Modern servisler için sinyal yöntemi tercih edilir. Uygulamanızı bir systemd servisi olarak çalıştırıyorsanız systemctl reload çoğu zaman doğru sinyali kendisi gönderir; servis birimi yazımı hakkında ayrıntı için yine systemd servis yönetimi rehberimize bakabilirsiniz.

Sık Yapılan Hatalar ve İyi Uygulamalar#

Yıllara yayılan deneyim, logrotate ile başın çoğu zaman aynı birkaç hatadan ağrıdığını gösteriyor. En yaygın olanı, /etc/logrotate.d/ altındaki dosyaya çalıştırma izni ya da yanlış uzantı vermektir. Bu dizindeki dosyalar düz metin yapılandırmadır; içinde nokta içeren adlar (app.conf gibi) logrotate tarafından atlanabilir, bu yüzden uzantısız sade adlar (app) kullanın. İkinci klasik hata, su direktifini ya da doğru sahipliği atlamaktır; döndürülen dosyanın sahibi yanlışsa uygulama yeni dosyaya yazamaz.

Bir diğer sık tuzak, döndürme sıklığı ile boyut sınırını karıştırmaktır. Zaman tabanlı daily/weekly ile boyut tabanlı size/maxsize birlikte kullanılabilir ama aralarındaki fark önemlidir. size 100M yazarsanız zaman koşulu tümüyle yok sayılır ve dosya yalnızca 100 MB'a ulaştığında döner. Buna karşılık maxsize 100M ile daily birlikte kullanıldığında dosya ya günlük ya da 100 MB'a ulaştığında (hangisi önce olursa) döner; yüksek trafikli sunucular için genellikle istediğiniz davranış budur.

Sağlıklı bir kurulum için birkaç pratik öneri:

# tüm yapılandırmaları hatasız mı diye topluca kontrol et
sudo logrotate -d /etc/logrotate.conf

# durum dosyasına bakarak neyin ne zaman döndüğünü gör
cat /var/lib/logrotate/status

# hangi büyük dosyalar diski yiyor, önce onları bul
sudo du -ah /var/log | sort -rh | head -20

Son olarak, uygulama loglarınızı işletim sisteminin /var/log yapısına uydurmaya çalışın ve saklama sürenizi ölçüsüz uzun tutmayın. 90 günlük ham erişim logu bir web sitesi için nadiren gereklidir; uzun süreli arşiv gerekiyorsa logları sıkıştırıp harici bir depolamaya taşımak (veya düzenli yedekleme çözümüne dahil etmek) hem diski korur hem de erişim güvenliğini artırır. Kritik sunucularda log yönetimini kendiniz üstlenmek istemiyorsanız, sunucu yönetimi hizmetimiz kapsamında bu tür rutin bakımları uzman ekibimiz sizin adınıza kurar ve izler.

Sıkça Sorulan Sorular#

logrotate zaten kurulu mu, nasıl kontrol ederim?#

Çoğu Debian, Ubuntu, AlmaLinux ve Rocky Linux kurulumunda logrotate varsayılan olarak gelir. Kurulu olup olmadığını logrotate --version komutuyla anında görebilirsiniz; bir sürüm numarası dönüyorsa hazırdır. Eğer bulunamazsa Debian tabanlı sistemlerde sudo apt install logrotate, RHEL tabanlılarda ise sudo dnf install logrotate komutuyla kurabilirsiniz.

logrotate günde bir kez çalışıyorsa saatlik döndürme nasıl yaparım?#

logrotate yapılandırmasına hourly yazmak tek başına yeterli değildir, çünkü onu tetikleyen zamanlayıcı yalnızca günde bir kez çalışır. Saatlik döndürme için önce yapılandırmaya hourly direktifini eklemeli, ardından logrotate'i saat başı tetikleyecek bir cron görevi ya da systemd timer tanımlamalısınız. Uygulamada bunu genellikle /etc/cron.hourly/ içine logrotate'i çağıran bir betik koyarak yaparsınız.

Döndürdüğüm halde disk hâlâ dolu, neden?#

En olası sebep, uygulamanızın döndürülen eski dosyaya yazmaya devam etmesidir. Klasik yeniden adlandırma yönteminde uygulama bir sinyalle uyarılmazsa açık handle'ı taşınan dosyaya bağlı kalır ve yeni log boş kalırken eski dosya büyümeye devam eder. Çözüm ya postrotate bloğuyla uygulamaya yeniden yükleme sinyali göndermek ya da sinyal desteklenmiyorsa copytruncate direktifini kullanmaktır.

logrotate yapılandırmasını değiştirdikten sonra servisi yeniden başlatmam gerekir mi?#

Hayır, logrotate sürekli çalışan bir servis değildir; bu yüzden yeniden başlatılacak bir daemon yoktur. Yapılandırma dosyasını kaydettiğiniz anda değişiklik geçerli olur ve logrotate bir sonraki çalıştığında yeni kuralları okur. Değişikliğin doğru olduğundan emin olmak için sudo logrotate -d ile önce simülasyonunu görmeniz yeterlidir.

dateext ile eski logların adında tarih nasıl çıkar?#

dateext direktifini yapılandırmaya eklediğinizde logrotate döndürülen dosyaları .1, .2 gibi sıralı sayılar yerine tarih ekiyle adlandırır; örneğin access.log-20260710 biçiminde. Tarih formatını dateformat -%Y%m%d gibi bir direktifle özelleştirebilirsiniz. Bu yöntem, hangi arşivin hangi güne ait olduğunu bir bakışta anlamayı çok kolaylaştırdığı için okunabilirlik açısından önerilir.

Yalnızca belirli bir dosyayı elle döndürmek istersem?#

Belirli bir yapılandırmayı zorla çalıştırmak için -f (force) bayrağını kullanırsınız; örneğin sudo logrotate -vf /etc/logrotate.d/app komutu sadece o dosyadaki kuralları hemen uygular. Buradaki -v yapılan işlemleri ekrana döker, -f ise zaman koşulunu beklemeden döndürmeyi tetikler. Test amaçlıysa gerçek durum dosyasını kirletmemek için --state /tmp/deneme.state ekleyerek geçici bir durum dosyası kullanmanız iyi olur.

Kapanış#

logrotate, karmaşık görünen ama aslında bir kez doğru kurulduğunda yıllarca sorun çıkarmadan çalışan o sessiz araçlardan biridir. Temel mantığı kavradığınızda gerisi bir avuç direktiften ibaret: ne sıklıkta döneceğini, kaç kopya saklanacağını, sıkıştırılıp sıkıştırılmayacağını ve döndürme sonrası uygulamanın nasıl haberdar edileceğini tanımlarsınız. logrotate -d ile test etme alışkanlığını edinirseniz, üretimde sürpriz yaşamadan güvenle çalışabilirsiniz. Unutmayın: iyi yönetilen loglar sunucunuzun hafızasıdır; kötü yönetilenler ise gece yarısı çalan alarmın ta kendisidir.

Sunucu bakımı, log yönetimi ve performans izlemesiyle uğraşmadan işinize odaklanmak isterseniz Clou.TR bu yükü sizden alır. Yüksek performanslı VDS sunucularımız ve tam yönetimli sunucu yönetimi hizmetimiz ile logrotate dahil tüm rutin bakımları uzman ekibimiz kurar ve izler; siz yalnızca uygulamanızı büyütmeye bakarsınız. Web projeleriniz için hızlı ve güvenli hosting paketlerimize de göz atmayı unutmayın.