Linux'ta Logu Sildim Ama Disk Hâlâ Dolu: Açık Dosyayı Bulalım

Büyük bir log dosyasını sildin, klasör küçüldü ama df -h hâlâ diski dolu gösteriyor. Burada hemen başka dosyaları silmeye başlama. Linux'ta dosyanın adının kaldırılmasıyla tuttuğu alanın serbest kalması her zaman aynı anda gerçekleşmiyor.

Bir süreç dosyayı açık tutuyorsa son dosya adı silinse bile içerik, son açık referans kapanana kadar yaşamaya devam edebilir. unlink sistem çağrısının açıklaması bu ayrımı yapıyor. Log artık dizin listesinde görünmez; uygulama ise eski açık dosyaya yazmayı sürdürebilir.

Önce aynı dosya sistemini ölçtüğümüzden emin olalım

df -hT /var/log
df -i /var/log
sudo du -xhd1 /var/log

/var/log yerine sildiğin dosyanın bulunduğu dizini kullan. df o yolu barındıran dosya sistemini, du ise gezebildiği dizinlerdeki dosyaların kullanımını ölçer. du -x farklı dosya sistemlerine geçmez. Dolayısıyla tüm kök bölümün df değeriyle yalnız /var/log toplamının eşit olmasını bekleme. Komutların kapsamı df ve du belgelerinde ayrılıyor.

df -i farklı bir soruya cevap verir: veri alanı dururken inode'lar mı bitmiş? Çok sayıda küçük dosya varsa sıkışıklığın nedeni gigabaytlar olmayabilir. Yetkisiz bir du taramasının erişemediği dizinler de hesabı eksik gösterebilir. Büyük üretim diskinde bütün dizin ağacını tekrar tekrar taramak yerine önce şüpheli bağlama noktasına odaklan.

Silinmiş dosyayı kim açık tutuyor?

sudo lsof -nP +L1

+L1, bağlantı sayısı birden küçük olan açık dosyaları seçer. İsim sütununda (deleted) görebilirsin. Her satırda süreç adı, PID, dosya tanımlayıcısı, aygıt ve inode bilgilerini birlikte oku. Seçeneğin ayrıntısı lsof kılavuzunda bulunuyor.

Listeyi “silinmiş olan her şey sorunlu” diye okuma. Küçük geçici dosyalar normal olabilir. Aradığımız, dolu dosya sisteminde anlamlı miktarda alan tutan dosya. Aynı inode birden çok süreçte veya tanımlayıcıda görünüyorsa satırların boyutunu doğrudan toplama; aynı içeriği tekrar sayabilirsin. SIZE/OFF sütununu da her dosya türü için ayrılmış fiziksel blok miktarı sanma.

lsof kurulu değilse sağlayıcının desteklediği depodan kurulabilir. Disk çok doluysa paket kurmak da başarısız olabilir; o durumda bir sonraki salt okunur kontrol kullanılabilir. Container veya farklı süreç görünürlüğü varsa bir listede sonuç çıkmaması makinenin tamamında açık dosya olmadığını garanti etmez.

Bulduğun PID'yi servise bağla

Aşağıdaki 12345 değeri örnek PID'dir; kendi çıktındaki PID ile değiştir:

ps -p 12345 -o pid,ppid,user,lstart,args
sudo ls -l /proc/12345/fd
sudo cat /proc/12345/cgroup

/proc/PID/fd dizini, sürecin açık dosya tanımlayıcılarını gösterir. cgroup bilgisi systemd birimi veya container ilişkisini araştırmaya yardımcı olabilir. İsim benziyor diye başka bir servisi yeniden başlatma; aynı uygulamanın birkaç örneği çalışıyor olabilir.

Özellikle MySQL, PostgreSQL veya başka bir veri servisinde açık görünen dosyayı sıradan log diye değerlendirme. Veritabanı, geçici çalışma dosyası veya uygulamanın başka bir kaynağı söz konusu olabilir. Dosyanın rolü belli değilse müdahaleyi burada durdur.

Alanı açmanın yolu dosyayı yeniden silmek değil

Dosya adı zaten kaldırılmış durumda. Yapılacak iş, dosyayı tutan uygulamanın açık tanımlayıcıyı güvenli biçimde bırakmasını sağlamak. Servis destekliyorsa belgelenmiş log yeniden açma yöntemi kullanılabilir. Bazı servislerde reload bunu yapar, bazılarında yapmaz. Bir servisin HUP sinyalini nasıl yorumladığını öğrenmeden sinyal gönderme.

Log yeniden açma yolu yoksa kontrollü servis yeniden başlatması gerekebilir. Önce bağımlılıkları, kesinti etkisini ve ilgili servisin yapılandırma testini değerlendir. “Nasıl olsa log” diyerek kill -9 kullanmak, bütün sunucuyu yeniden başlatmak veya /proc/PID/fd/N yolunu sıfırlamak güvenli varsayılanlar değil. Bu yazıdaki komutlar bu yüzden teşhis aşamasında yalnız okuma yapıyor.

Genel disk doluluğu için Linux disk doluluğu kontrolleri, dizin karşılaştırması için de du ve ncdu ile klasör boyutu yazısı kullanılabilir. Burada peşinde olduğumuz daha dar: dosya adı gitmişken alanı tutan açık referans.

Son tanımlayıcı kapandı mı?

sudo lsof -nP +L1
df -hT /var/log

İlgili dosyanın tüm açık referansları listeden kaybolmalı. Beklediğin alanın açılıp açılmadığını aynı dosya sisteminde kontrol et; yoğun yazma devam ediyorsa net değişim dosya boyutuyla birebir olmayabilir. Ardından uygulamanın yeni log dosyasını oluşturduğunu ve oraya yazdığını doğrula. Dosya kapanmış ama alan farkı sürüyorsa aynı müdahaleyi tekrarlamak yerine snapshot, bağlama noktası ve dosya sistemi hesabı gibi diğer nedenleri incele.