Disk Doldu Hatası Çözümü: Linux Sistemlerde Kök Neden Analizi ve Acil Müdahale Rehberi
Linux sunucularda kritik anlarda karşımıza çıkan disk doldu hatasının (No space left on device) kök nedenlerini analiz edin, acil müdahale adımlarını uygulayın ve kalıcı önlemler alın.
Caner Serbest
Sistem ve Altyapı
4 dk okuma
Disk Doldu Hatası Çözümü: Linux Sistemlerde Kök Neden Analizi ve Acil Müdahale Rehberi
Gece yarısı telefonunuza gelen bir alarm veya izleme aracından düşen kritik bir uyarı: “No space left on device”. Servisler yanıt vermiyor, veritabanları yazma işlemlerini durdurdu ve kullanıcılar hata sayfalarıyla karşılaşıyor. Bir sistem yöneticisinin veya operasyon mühendisinin en sık karşılaştığı ancak en çok stres yaratan senaryolardan biri tam olarak budur.
Disk doluluğu yalnızca “biraz veri silip geçelim” denilebilecek basit bir alan yetersizliği problemi değildir. Çoğu zaman altta yatan bir otomasyon hatasının, şişen log dosyalarının veya sızıntı yapan (leak) bir uygulamanın habercisidir. Bu rehberde, Linux tabanlı sunucularda disk doldu hatasıyla karşılaşıldığında izlenmesi gereken acil müdahale adımlarını, kök neden analizini ve bir daha bu durumla karşılaşmamak için alınması gereken proaktif önlemleri ele alacağız.
1. Acil Durum: Servisler Durmadan Önce İlk Müdahale
Disk tamamen dolduğunda, birçok Linux çekirdeği süreci (process) yeni dosya oluşturamayacağı için aniden kilitlenebilir veya çökebilir. Bu aşamada panikle rastgele dosyaları silmek yerine, sistematik bir triyaj (önceliklendirme) süreci izlemek gerekir.
Adım 1: Durumu Netleştirin (df Komutu)
İlk olarak hangi bölümün (partition) tamamen dolduğunu tespit etmeliyiz:
df -h
Bu komut çıktısında %100 doluluk oranına sahip olan alanı (/, /var, /home vb.) bulun. Eğer kök dizin (/) dolduysa sistem kritik düzeyde tehlike altındadır.
Adım 2: Gizli Alan Tüketicilerini Bulun (du Komutu)
En büyük dizinleri tespit etmek için du komutunu kullanırız. Kök dizine giderek en çok yer kaplayan alt dizinleri listeleyelim:
cd /
du -h --max-depth=1 2>/dev/null | sort -hr
Not: 2>/dev/null parametresi, erişim iznimiz olmayan dizinlerden (örneğin /root veya özel log klasörleri) gelebilecek hata mesajlarını gizler. Genellikle suçlu /var, /tmp veya /usr/local altındaki devasa dosyalardır.
2. Kök Neden Analizi: Alanı Neresi Tüketti?
Alanı tüketen ana dizini bulduktan sonra, spesifik olarak hangi dosyaların bu soruna yol açtığını bulmalıyız. Sık karşılaşılan senaryolar şunlardır:
Senaryo A: Şişen Log Dosyaları
Eğer /var/log dizini dolmuşsa, log rotasyon mekanizması düzgün çalışmıyor olabilir veya bir uygulama aşırı miktarda hata (error/debug) üretmektedir.
find /var/log -type f -exec du -h {} + | sort -hr | head -n 10
Bu komut, /var/log altındaki en büyük 10 dosyayı listeleyecektir.
Senaryo B: Silinmiş Ama Süreci Kapanmamış Dosyalar (The Ghost Files)
Sistem yöneticilerinin en sık düştüğü tuzaklardan biri budur: rm -rf ile büyük bir log dosyasını sildiğinizi düşünürsünüz ancak dosyayı kullanan bir servis (örneğin Nginx, Docker veya bir veritabanı) hala açık tuttuğu için disk alanı boşalmaz.
Bunu tespit etmek için şu komut çalıştırılır:
lsof +L1
Veya alternatif olarak:
lsof | grep deleted
Çözüm: Bu durumda dosyayı silen süreci (PID) yeniden başlatmanız veya sonlandırmanız gerekir. Süreç kapandığı an, işletim sistemi disk alanını gerçekten serbest bırakacaktır.
Senaryo C: Docker İmajları, Konteynerler ve Volume’ler
Docker kullanan sunucularda disk dolmasının bir numaralı sebebi kullanılmayan imajlar (dangling images), durdurulmuş konteynerler ve şişen build cache’leridir.
Durumu kontrol etmek için:
docker system df
Kullanılmayan tüm artıkları temizlemek için ise şu komut hayat kurtarır:
docker system prune -a --volumes
(Dikkat: Bu komut aktif olarak kullanılmayan tüm imaj ve volume’leri siler, üretim ortamında dikkatli kullanılmalıdır.)
3. Inode Tükenmesi: Disk Var Ama Dosya Yazılamıyor
Bazen df -h komutuna baktığınızda diskte hala gigabaytlarca boş alan görürsünüz ancak sistem hala “No space left on device” hatası vermeye devam eder. Bunun sebebi Inode tükenmesidir.
Linux dosya sistemleri, dosya verilerini tutmak için inode yapılarını kullanır. Eğer sisteminizde milyonlarca küçük dosya (örneğin cache dosyaları, küçük oturum dosyaları veya e-posta kuyrukları) varsa, diskte yer olsa bile inode’lar bittiği için yeni dosya oluşturulamaz.
Inode durumunu kontrol etmek için:
df -i
Eğer bir dizinde (genellikle /var/spool/mail veya /tmp) çok fazla küçük dosya birikmişse, bunları temizlemek gerekir. Örneğin, belirli bir dizindeki binlerce geçici dosyayı silmek için:
find /path/to/target -type f -mtime +7 -delete
4. Kalıcı Çözümler ve Proaktif Önlemler
Bir daha aynı gece yarısı alarmıyla uyanmamak için operasyonel süreçlerinize aşağıdaki maddeleri entegre etmelisiniz:
1. Logrotate Yapılandırması
Asla log dosyalarının sınırsız büyütülmesine izin vermeyin. /etc/logrotate.d/ altında ilgili servis için uygun bir yapılandırma olduğundan emin olun. Örnek bir Nginx logrotate kuralı:
/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}
2. Disk İzleme ve Erken Uyarı Sistemi
Diskin %100 dolmasını beklemeyin. Zabbix, Prometheus veya basit bir Bash betiği ile disk doluluğu %80’i geçtiğinde uyarı (warning), %90’ı geçtiğinde ise kritik alarm üretecek mekanizmalar kurun.
Örnek basit bir disk kontrol betiği cron’a eklenebilir:
#!/bin/bash
THRESHOLD=90
CURRENT=$(df / | grep / | awk '{ print $5 }' | sed 's/%//g')
if [ "$CURRENT" -gt "$THRESHOLD" ]; then
echo "Kritik: Kök dizin doluluk oranı %$CURRENT seviyesine ulaştı!" | mail -s "Disk Uyarısı" [email protected]
fi
3. Periyodik Temizlik Rutinleri
Sistemde zamanla biriken paket yöneticisi önbelleklerini periyodik olarak temizleyin:
# Debian/Ubuntu tabanlı sistemler için
apt-get clean
apt-get autoremove --purge
Sonuç
Disk doldu hatası, sistem yönetiminde disiplinin ne kadar önemli olduğunu gösteren net bir göstergedir. Anlık müdahaleler (dosya silme, docker prune vb.) sadece yangını söndürür; asıl kalıcı çözüm ise log yönetimi, inode takibi ve proaktif izleme altyapısının kurulmasıdır. Sunucularınızı izlenebilir kıldığınızda, bu tür krizler kaotik birer acil duruma değil, rutin operasyonel adımlara dönüşecektir.
Bu yazı Gemini ile otomatik oluşturulmuştur.