Üretimde kernel panic yaşandığında iki uç senaryo görürsün: “makine reboot etti geçti” veya “saatlerce nedenini bulamadık”. Özellikle storage driver’ları, NIC offload, kernel güncellemeleri ve donanım kaynaklı sorunlarda, panikten sonra geriye kalacak en değerli artefakt vmcore’dur.
kdump, panic anında ikinci bir kernel ile açılıp bellek dump’ını alır ve “kanıt” bırakır. Bu yazı bir “sadece kurulum” rehberi değil; dump’ı alıp saklamayı, test etmeyi ve incident akışına bağlamayı hedefler.
Ön koşullar: kdump’u üretimde sürdürülebilir yap
kdump için üç gerçeği kabul et:
- Dump büyük olabilir (RAM boyutuna bağlı)
- Dump’ı lokal diskte tutmak her zaman güvenli değildir
- Panic “nadiren” olur; bu yüzden test edilmezse çalışmayabilir
Bu nedenle başlangıç hedefin:
- dump hedefini netleştir (lokal + merkezi kopya)
- disk alanı ve retention politikası koy
- düzenli test planı yaz
1) Crash kernel rezervasyonu (crashkernel)
kdump’un çalışması için bellekten bir bölüm “crash kernel”e ayrılır. Bu genelde kernel boot parametresiyle yapılır.
Örnek yaklaşım (dağıtıma göre değişir):
- Bootloader’da
crashkernel=parametresini set et - Reboot sonrası rezervasyonu doğrula
Doğrulama için:
cat /proc/cmdline
dmesg | rg -i "crashkernel|reserved"2) kdump servisinin kurulumu ve enable edilmesi
Dağıtımına göre paket isimleri farklı olabilir; ama mantık aynıdır:
- kdump/kexec araçlarını kur
- kdump servisini enable et
- Dump hedefini ayarla (lokal disk / NFS / SSH / object storage gateway)
Durum kontrolü:
systemctl status kdump || true
kdumpctl status || true3) Dump hedefi: “yazabildiğim tek yer” değil “kurtarabileceğim yer”
Benim sahada güvenli bulduğum iki katmanlı model:
- Birincil: lokal disk (hızlı yazım, reboot sonrası hazır)
- İkincil: merkezi depo (NFS/SSH) → incident analizi için erişilebilir
Eğer merkezi hedef kullanıyorsan:
- Ağ yolunu kısıtla (sadece dump trafiği)
- Kimlik/anahtar yönetimini sertleştir
- Dump’ların PII içerebileceğini varsay (erişim ve retention)
4) Test: kontrollü panic tetikle ve doğrula
Üretimde “ilk panic” anında öğrenmek istemezsin. Pilot ortamda kontrollü test yap:
echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-triggerSistem panic olup reboot edecektir. Sonrasında dump dosyası üretildi mi kontrol et:
ls -lah /var/crash || true5) Triage runbook: vmcore ile ilk 30 dakika
Panic sonrası ilk hedef “kök nedeni anında çözmek” değil, kanıtı korumak ve sınıflandırmak olmalı.
Benim 30 dakikalık akışım:
- Dump dosyasının varlığını doğrula (lokal ve/veya merkezi)
- Kernel sürümü / build ID / uptime bilgisini not al
- Son değişiklikleri kontrol et: kernel update, NIC/driver, firmware, workload değişimi
- Eğer tekrar ediyorsa: aynı ring’de mi, aynı donanım mı?
- vmcore’la analiz için “crash” ortamını hazırla (offline)
İlk kanıt paketi:
vmcoredmesg/journalctl -b -1uname -a- değişiklik kaydı (change/ticket)
6) Üretim disiplini: retention ve maliyet
Dump’lar büyük olabilir. Politika önerisi:
- Her host için “son 1 dump” tut
- Merkezi depoda 7–30 gün retention
- Kritik sistemlerde dump’ı otomatik “evidence bundle”a bağla
Sonuç
kdump, kernel panic’i “görünmez reboot” olmaktan çıkarıp analiz edilebilir bir olaya dönüştürür. Gerçek değer; crashkernel ayarı, dump hedefi, test planı ve triage runbook’un birlikte tasarlanmasıyla ortaya çıkar. Üretimde süreklilik istiyorsan, en zor hatalar için bile kanıt bırakabilen bir altyapı kurmak zorundasın.