Linux'ta D-State Nedir? İşlem Neden kill -9 ile Kapanmaz?

Yorumlar

kill -9 komutundan sonra süreç hâlâ listede görünüyorsa ilk şüphe “Linux sinyali iletemedi” olmamalıdır. Süreç D durumundaysa çekirdek içinde kesilemeyen bir beklemededir. SIGKILL beklemeye alınır; süreç çekirdek yolundan çıkabildiği anda uygulanır.

Sürecin gerçekten D-State olduğunu doğrulayın

BASH

ps -eo state,pid,ppid,wchan:32,comm,args | awk '$1 ~ /^D/'

TEXT

D  18422  17201 nfs_wait_bit_killable  cp  cp /mnt/archive/a.img /var/tmp/

ps durum kodlarında D, genellikle I/O bekleyen kesilemez uykuyu ifade eder. Süreç CPU tüketmiyor olabilir; fakat beklediği kernel işlemi tamamlanmadığı için kullanıcı alanına dönemiyordur. Tek seferlik bir D kaydı arıza kanıtı değildir. Aynı PID dakikalarca kalıyorsa ve bekleyen süreç sayısı artıyorsa örneklemeyi sürdürün:

BASH

for i in {1..6}; do
  date
  ps -o pid,ppid,state,wchan:32,etime,comm -p 18422
  sleep 10
done

`wchan` hangi bağımlılığa bakacağınızı söyler

BASH

cat /proc/18422/wchan
sudo cat /proc/18422/stack

wchan, görevin çekirdek içinde uyuduğu işlevin sembolik adını gösterir. İsimler kernel sürümüne göre değişir; tek başına kesin kök neden değildir.

İşaret	Muhtemel alan	Sonraki kontrol
`nfs_`, `rpc_`	NFS sunucusu veya ağ yolu	`nfsstat -m`, mount seçenekleri ve sunucu erişimi
`io_schedule`, `wait_on_page*`	Blok aygıtı veya dosya sistemi	`dmesg`, disk gecikmesi ve multipath
`jbd2_*`	ext4 journal işlemi	Aygıt hataları ve dosya sistemi olayları
FUSE ile ilişkili çerçeve	Kullanıcı alanı dosya sistemi	FUSE daemon’u ve arka uç bağımlılığı

/proc/PID/stack için root yetkisi ve uygun kernel yapılandırması gerekebilir. Dosya boşsa veya erişim reddedilirse bunu sürecin sağlıklı olduğu şeklinde yorumlamayın.

Kernel günlüğünü süreç bilgisiyle aynı zamana koyun

BASH

sudo journalctl -k --since '-15 min' --no-pager
sudo dmesg -T | tail -n 100

NFS “server not responding” mesajları, SCSI/NVMe zaman aşımı ve reset kayıtları, I/O error veya “task blocked for more than” satırları kök nedeni daraltır. Yalnızca süreç adını görüp servisi yeniden başlatmak, alttaki depolama veya ağ beklemesini çözmeyebilir; aynı kaynağı kullanan yeni süreçleri de D-State’e sokabilir.

Tüm bloke görevleri tek seferde dökün

Magic SysRq’nin w işlemi kesilemez durumda bekleyen görevleri kernel günlüğüne yazar:

BASH

echo w | sudo tee /proc/sysrq-trigger
sudo journalctl -k -n 250 --no-pager

Bu işlem süreçleri öldürmez veya sistemi yeniden başlatmaz; tanılama çıktısı üretir. Çok sayıda bloke görev varsa günlüğe yoğun veri yazabileceği için olay kaydına saat ve gerekçe ekleyin.

Neden yeni `kill -9` denemeleri işe yaramaz?

BASH

sudo kill -KILL 18422
grep -E 'State|SigPnd|ShdPnd' /proc/18422/status

SIGKILL engellenemez veya yakalanamaz; fakat süreç kernel içindeki kesilemez beklemeden çıkana kadar sinyal işlenmez. Komutu döngü içinde tekrar göndermek depolama cevabını hızlandırmaz.

Müdahaleyi beklenen kaynağa göre seçin

NFS: Sunucu ve dönüş yolu erişimini düzeltin. Bağlantıyı körlemesine soft yapmayın; belirli iş yüklerinde veri bütünlüğü riski oluşturabilir.
Yerel disk: Kernel hataları, SMART/NVMe sağlığı, denetleyici ve multipath durumunu kontrol edin. Hatalı aygıta yeni I/O göndermeyi azaltın.
FUSE: Dosya sistemi daemon’unun durumunu, açık dosyaları ve arka uç servisini kontrol edin.
Yanıt vermeyen donanım: Yeniden başlatma son çare olabilir; önce log ve stack çıktısını toplayın, bekleyen yazmaların etkisini değerlendirin.

Beklemenin çözüldüğünü doğrulayın

BASH

ps -p 18422 -o pid,state,wchan,etime,comm
ps -eo state,pid,wchan:32,comm | awk '$1 ~ /^D/'
sudo journalctl -k --since '-5 min' --no-pager

İlk komut yalnızca başlık döndürüyorsa bekleyen SIGKILL uygulanmış ve süreç kapanmıştır. Süreç yaşıyor fakat durum S veya R olduysa kernel beklemesinden çıkmıştır; normal servis durdurma veya uygulama teşhisi artık anlamlıdır. Yeni D-State süreçleri oluşuyorsa kapatılan PID’ye değil ortak I/O bağımlılığına dönün.

Teknik başvuru: ps durum kodları, /proc/PID/stat ve Linux Magic SysRq.