Linux'ta Logrotate Çalışıyor mu? Zamanlama, Döndürme ve Yeni Log Kontrolü

Log dosyası büyüyor, yanında birkaç tane .gz dosyası da var. Bu görüntü logrotate'ın bugün düzgün çalıştığını kanıtlamaz. Eski arşivler geçen aydan kalmış olabilir; uygulama da döndürülmüş dosyaya yazmayı sürdürüyor olabilir.

Log döndürme, büyüyen dosyayı arşive ayırıp uygulamanın yeni bir dosyaya yazmasını sağlama işidir. Logrotate bunun zamanını, saklanacak kopya sayısını ve sıkıştırma politikasını yönetir. Kontrolü üçe ayıralım: zamanlayıcı çalışıyor mu, dosya döndürülmeye uygun mu, uygulama yeni dosyaya geçmiş mi?

Zamanlayıcıya bak, hemen zorla çalıştırma

systemd kullanan birçok dağıtımda logrotate bir timer ile çağrılır. Timer, görevin ne zaman tetikleneceğini tanımlar; servis de asıl komutu yürütür. İlk bakılacak yer son çalışmanın zamanı ve hata kaydı:

systemctl list-timers --all logrotate.timer
systemctl status logrotate.timer logrotate.service --no-pager
sudo journalctl -u logrotate.service --since "2 days ago" --no-pager

Tek seferlik çalışan servis işini bitirdikten sonra inactive görünebilir. Bu tek başına arıza değil; son çıkış koduna ve bir sonraki zamanlamaya bak. Timer bulunmuyorsa cron kullanan bir kurulum olabilir. Yerel /etc/cron.daily/ ve cron tanımlarını kontrol et; her dağıtımda aynı dosya adı veya servis yapısı olmayabilir.

logrotate -f, “bir bakalım” komutu değildir; koşullar beklemeden gerçek döndürme yapabilir, yapılandırmaya bağlı olarak eski arşivleri kaldırabilir ve servis komutlarını çalıştırabilir. Önce değişiklik yapmayan incelemeyi kullanacağız.

Ana yapılandırmayı debug ile oku

sudo logrotate --debug /etc/logrotate.conf

--debug, kararları gösterir; log dosyalarını veya durum dosyasını değiştirmez. Çıktıda dosyanın neden döndürülmediğini, hangi kuralın okunduğunu ve yapılandırma hatalarını ara. Sadece uygulamanın küçük dosyasını denersen ana dosyadaki genel ayarları atlayabilirsin. Servisin gerçekte hangi yapılandırmayla çağrıldığını da karşılaştır.

Logrotate son işlemleri bir durum dosyasında tutar. Yol paket ve servis çağrısına göre değişebilir; sistemindeki kullanım belgesi ve servis tanımını esas al. Debug çıktısında bu kayıtla verilen karar birbirini açıklamalı. Durum dosyasını silmek teşhis değildir; sonraki zaman kararını da değiştirebilir.

“daily” dosya 24 saatte bir uyanır demek değil

daily, logrotate çağrıldığı zaman günlük döndürmeye uygunluğu değerlendirir. Program çağrılmıyorsa kuralın kendisi işlem başlatmaz. Aynı şekilde maxsize sınırının aşılması anında alarm kurmaz; kontrol ancak bir sonraki çalışmada yapılır. Çok hızlı büyüyen bir dosyada yalnız boyut eşiğini küçültmek yerine çalıştırma sıklığını da düşünmek gerekir.

size ile daily gibi zaman kuralları aynı anlama gelmez; yapılandırmadaki sıra da önemlidir. “Günlük döndür ama boyut büyürse daha erken de değerlendir” ihtiyacında maxsize davranışını incele. minsize ise zaman koşulunun yanında asgari boyut şartı ekler. Kuralların ayrıntıları logrotate kullanım belgesinde bulunuyor.

Yeni dosya oluştu, peki uygulama ona yazıyor mu?

Dosyayı yeniden adlandırmak açık dosya tanıtıcısını değiştirmez. Uygulama eski dosyaya yazmayı sürdürebilir. Yönetmek istediğin uygulamanın desteklediği “log dosyasını yeniden aç” yöntemini öğren; postrotate bölümünde çağrılan komut bunun için vardır. Bir servis için geçerli sinyali başka bir servise kopyalamak doğru değil.

Aşağıdaki incelemede uygulama dizini örnektir; kendi log yolunla değiştir. ls -li dosyanın inode numarasını da gösterir. Inode, dosyanın dosya sistemi içindeki kimliğidir:

sudo ls -li /var/log/uygulama/
sudo lsof /var/log/uygulama/app.log
sudo lsof +L1

Son komut silinmiş ama açık tutulan dosyaları listeler; yoğun sistemde çıktı geniş olabilir. Yeni dosya boş kalırken eski dosya büyüyorsa uygulamanın yeniden açma adımına dön. Dosyayı silip disk boşaltmaya çalışma; bu durum silinmiş ama açık log rehberindeki sorunu doğurabilir.

copytruncate bazı uygulamalarda yeniden açma ihtiyacını aşmak için kullanılır: içerik kopyalanır, mevcut dosya kısaltılır. Ancak iki işlem arasında yazılan veriler kaybolabilir. Özellikle olay incelemesinde önemli kayıtları tutuyorsan bunu zararsız bir varsayılan sayma. create ile oluşturulan yeni dosyanın sahibi ve izinleri de uygulamanın yazabilmesi için doğru olmalı.

Bir sonraki gerçek çalışmayı takip et

Yapılandırma düzeltildikten sonra debug kontrolünü tekrarla. Normal zamanlama veya planlı gerçek döndürme sonrasında üç şeyi kontrol et: servis başarılı mı, beklenen arşiv oluşmuş mu, yeni log dosyası yeni isteklerle büyüyor mu? Yalnız .1 dosyasının görünmesi işi tamamlamaz.

Disk kullanımının asıl kaynağı systemd-journald ise düz metin log kurallarını değiştirmek aynı alanı yönetmez. Journal'ın saklama politikası ayrıdır. Hangi dosyanın büyüdüğünü belirleyip o kaynağın döndürme davranışını doğrula.