Kernel Panic Analizi: Linux Crash Dump İnceleme Rehberi

Bykomut

Gece 2’de telefonun çaldığını ve “sunucu çöktü” mesajını gördüğünü düşün. Ekrana baktığında seni karşılayan şey o meşhur “Kernel Panic – not syncing” satırı. İşte bu noktada panikleyen sen değil, kernel olmalı. Crash dump analizi tam olarak bunun için var: sistemin son nefesini kayıt altına alıp, neyin yanlış gittiğini anlamana yardımcı oluyor.

Bu yazıda Linux kernel panic durumlarını, crash dump’ların nasıl toplanacağını ve analiz edileceğini gerçek dünya senaryolarıyla ele alacağız. Sadece teorik değil, elle tutulur, terminale yazabileceğin şeyler konuşacağız.

Kernel Panic Nedir ve Neden Olur?

Kernel, bir hatadan kurtarmanın mümkün olmadığını tespit ettiğinde sistemi tamamen durdurur. Bu, Windows’taki “Blue Screen of Death”in Linux karşılığıdır ama çok daha fazla bilgi sunar. Kernel panic’in yaygın nedenleri şunlardır:

  • Donanım arızaları: Bozuk RAM, disk hatası, CPU sıcaklık sorunu
  • Sürücü hataları: Hatalı yazılmış veya uyumsuz kernel modülleri
  • Bellek bozulması: NULL pointer dereference, buffer overflow
  • Dosya sistemi hataları: Mount edilemeyen root filesystem
  • Kernel bug’ları: Özellikle güncel olmayan kernel sürümlerinde

Bir kernel panic mesajı genellikle şuna benzer:

Kernel panic - not syncing: Fatal exception in interrupt
CPU: 2 PID: 1847 Comm: nginx Not tainted 5.15.0-76-generic
Hardware name: Dell Inc. PowerEdge R740/...
Call Trace:
 dump_stack_lvl+0x49/0x65
 panic+0x101/0x2d0
 ...

Bu çıktıyı ekrandan okumak zorunda kalmamak için crash dump mekanizmasını kurman gerekiyor.

Kdump Kurulumu ve Yapılandırması

kdump, kernel panic anında bellek içeriğini diske yazan mekanizmadır. Çalışma mantığı şudur: sistem başladığında küçük bir “capture kernel” için bellek rezerve edilir. Panic anında bu capture kernel devreye girer ve ana kernel’ın bellek dump’ını bir dosyaya yazar.

Ubuntu/Debian Sistemlerde Kurulum

# Gerekli paketleri kur
sudo apt update
sudo apt install -y kdump-tools crash linux-crashdump

# Servis durumunu kontrol et
sudo systemctl status kdump-tools

# Yapılandırma dosyasını düzenle
sudo nano /etc/default/kdump-tools

Yapılandırma dosyasında şu satırları ayarla:

# /etc/default/kdump-tools
USE_KDUMP=1
KDUMP_COREDIR="/var/crash"
KDUMP_NUM_DUMPS=5
MAKEDUMP_ARGS="-c -d 31"

RHEL/CentOS/Rocky Linux Sistemlerde Kurulum

# Paketleri kur
sudo dnf install -y kexec-tools crash kernel-debuginfo

# kdump servisini etkinleştir
sudo systemctl enable --now kdump

# Yapılandırma dosyası
sudo nano /etc/kdump.conf
# /etc/kdump.conf temel ayarlar
path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31
default reboot

GRUB ile Crashkernel Bellek Ayarı

Kdump’ın çalışması için GRUB’da bellek rezervasyonu yapman gerekiyor:

# /etc/default/grub dosyasını düzenle
sudo nano /etc/default/grub

# GRUB_CMDLINE_LINUX satırına ekle:
# crashkernel=256M (genel öneri)
# crashkernel=auto (sistem otomatik belirlesin)

GRUB_CMDLINE_LINUX="crashkernel=256M quiet splash"

# GRUB'u güncelle
sudo update-grub  # Ubuntu/Debian
sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL/CentOS

Değişikliğin aktif olması için sistemi yeniden başlatman gerekiyor. Sonrasında rezervasyonu doğrula:

# Crashkernel belleğinin rezerve edildiğini kontrol et
cat /proc/cmdline | grep crashkernel
dmesg | grep -i crashkernel

Test: Bilinçli Kernel Panic Tetikleme

Kurulum doğru çalışıyor mu? Bunu test ortamında doğrulamak için kernel’ı kasıtlı olarak panic’e sürükleyebilirsin. Bunu asla production ortamında yapma.

# SysRq ile kernel panic tetikleme
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

# Alternatif: /proc/sys üzerinden
echo "c" | sudo tee /proc/sysrq-trigger

Sistem yeniden başladıktan sonra dump dosyasını kontrol et:

# Dump dosyasının oluştuğunu doğrula
ls -lh /var/crash/
# Çıktı:
# drwxr-x--- 2 root root 4096 Jun 15 02:34 2024-06-15-02:34:17/

ls -lh /var/crash/2024-06-15-02:34:17/
# vmcore          (ana dump dosyası)
# vmcore-dmesg.txt (kernel mesajları)

Crash Dump Analizi: crash Aracı

crash aracı, vmcore dosyalarını analiz etmek için kullanılan güçlü bir debugger’dır. GDB’ye benzer bir arayüze sahiptir ama kernel yapılarını anlar.

Crash Aracını Başlatma

# crash'i vmcore ve kernel ile başlat
sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/2024-06-15-02:34:17/vmcore

# RHEL sistemlerde
sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/vmcore

Başarılı bir başlatma şöyle görünür:

crash 8.0.3
Copyright (C) 2002-2022  Red Hat, Inc.
...
      KERNEL: /usr/lib/debug/boot/vmlinux-5.15.0-76-generic
    DUMPFILE: /var/crash/2024-06-15-02:34:17/vmcore
        CPUS: 8
        DATE: Fri Jun 15 02:34:17 UTC 2024
      UPTIME: 14 days, 06:23:41
LOAD AVERAGE: 0.45, 0.38, 0.32
       TASKS: 487
    NODENAME: web-prod-01
     RELEASE: 5.15.0-76-generic
     VERSION: #83-Ubuntu SMP Thu Jun 15 19:16:32 UTC 2023
     MACHINE: x86_64
      MEMORY: 32 GB
       PANIC: "Kernel panic - not syncing: Fatal exception"
         PID: 1847
     COMMAND: "nginx"
        TASK: ffff9a8b12345678  [THREAD_INFO: ffff9a8b12345678]
         CPU: 2
       STATE: TASK_RUNNING (PANIC)

crash>

Temel crash Komutları

İşte crash içinde en çok kullanacağın komutlar:

# Panik anındaki backtrace (stack trace) görüntüle
crash> bt
# veya belirli bir PID için
crash> bt 1847

# Tüm CPU'ların stack trace'ini göster
crash> bt -a

# Kernel mesajlarını görüntüle (dmesg)
crash> log

# Son N satırı göster
crash> log | tail -50

# Çalışan process listesi
crash> ps

# Belirli durumda takılı kalmış processler
crash> ps | grep UN

Gerçek bir backtrace çıktısı şöyle görünür:

crash> bt
PID: 1847   TASK: ffff9a8b12345678  CPU: 2   COMMAND: "nginx"
 #0 [ffffa2b4c0f63d40] machine_kexec at ffffffff8105e4e1
 #1 [ffffa2b4c0f63d98] __crash_kexec at ffffffff811b59c2
 #2 [ffffa2b4c0f63e60] crash_kexec at ffffffff811b6ab0
 #3 [ffffa2b4c0f63e78] oops_end at ffffffff8101db58
 #4 [ffffa2b4c0f63ea0] no_context at ffffffff810762e0
 #5 [ffffa2b4c0f63ef8] __bad_area_nosemaphore at ffffffff81076598
 #6 [ffffa2b4c0f63f48] bad_area_nosemaphore at ffffffff810766d6
 #7 [ffffa2b4c0f63f58] do_page_fault at ffffffff81077b14
 #8 [ffffa2b4c0f63f80] page_fault at ffffffff8179d8c8
    [exception RIP: ngx_http_process_request+0x123]

Bu çıktı bize nginx’in HTTP isteği işlerken bir page fault’a yol açtığını gösteriyor.

Gerçek Senaryo 1: NULL Pointer Dereference

Üretim ortamında sık karşılaşılan bir senaryo: özel bir kernel modülü NULL pointer’ı dereference ediyor.

crash> log | grep -A5 "BUG:"
# Çıktı:
# BUG: kernel NULL pointer dereference, address: 0000000000000048
# PGD 0 P4D 0
# Oops: 0002 [#1] SMP PTI
# CPU: 2 PID: 1847 Comm: nginx Tainted: G           O  5.15.0-76

Hangi modülün tainted ettiğini bulmak için:

crash> mod
# Yüklü modüllerin listesini gösterir
# O: Out-of-tree (resmi kernel'dan değil)
# Tainted işaretli modüllere dikkat et

crash> sys
# Sistem bilgisi ve tainted flag detayları

Bellek adresini analiz etmek için:

# Hatalı adresi incele
crash> rd ffff9a8b12345678 16

# Struct bilgisi görüntüle
crash> struct task_struct ffff9a8b12345678

# Symbol arama
crash> sym ngx_http_process_request

Gerçek Senaryo 2: Memory Exhaustion ve OOM Killer

Sistemin belleği tükenip OOM (Out of Memory) killer devreye girdiğinde de crash dump işe yarıyor:

# vmcore-dmesg.txt içinde OOM mesajlarını ara
grep -i "out of memory|oom|killed process" /var/crash/*/vmcore-dmesg.txt

# crash içinde bellek durumunu incele
crash> kmem -i

# Çıktı örneği:
#                  PAGES      TOTAL  PERCENTAGE
#     TOTAL MEM  8126464      31 GB         ----
#          FREE    12847      50 MB    0% of TOTAL MEM
#          USED  8113617      31 GB   99% of TOTAL MEM

Hangi processler en fazla bellek kullanıyordu?

crash> ps -G
# Process gruplarını bellek kullanımıyla listeler

# Belirli bir process'in detayları
crash> task 1847
crash> vm 1847

Gerçek Senaryo 3: Disk I/O Hatası Kaynaklı Panic

# Kernel log içinde I/O hatalarını ara
crash> log | grep -i "i/o error|blk_|ata[0-9]"

# Block device durumunu incele
crash> dev -d

# Çıktıda şöyle bir şey görebilirsin:
# ata2.00: status: { DRDY ERR }
# ata2.00: error: { UNC }
# end_request: I/O error, dev sda, sector 1048576

Bu durumda genellikle disk donanım arızası veya RAID bozulması söz konusudur. Fiziksel diski kontrol etmen gerekir.

makedumpfile ile Dump Boyutunu Küçültme

Tam bir vmcore dosyası onlarca GB olabilir. makedumpfile bu boyutu önemli ölçüde azaltır:

# Sadece kernel sayfalarını tut (-d 31 en agresif filtreleme)
sudo makedumpfile -c -d 31 /proc/vmcore /var/crash/compressed-vmcore

# Filtreleme seviyeleri:
# -d 1: Zero sayfaları hariç tut
# -d 2: Cache sayfaları hariç tut
# -d 4: Cache private sayfaları hariç tut
# -d 8: User sayfaları hariç tut
# -d 16: Free sayfaları hariç tut
# -d 31: Hepsini uygula (önerilen)

# Boyut karşılaştırması
ls -lh /proc/vmcore                    # Genellikle RAM boyutu kadar
ls -lh /var/crash/compressed-vmcore   # Genellikle %10-20'si

vmcore-dmesg.txt Analizi

Crash aracını kurmadan veya debug sembollerine sahip olmadan bile vmcore-dmesg.txt dosyası çok değerli bilgiler sunar:

# Temel inceleme
cat /var/crash/*/vmcore-dmesg.txt | less

# Panic mesajını bul
grep -A 50 "Kernel panic" /var/crash/*/vmcore-dmesg.txt

# Call trace'i çıkar
grep -A 100 "Call Trace:" /var/crash/*/vmcore-dmesg.txt | head -60

# Hardware hatalarını ara
grep -iE "mce|corrected|uncorrected|edac|memory error" /var/crash/*/vmcore-dmesg.txt

decode_stacktrace.sh ile Okunabilir Stack Trace

Kernel kaynak koduna erişimin varsa stack trace adreslerini işlev isimlerine çevirebilirsin:

# Kernel kaynak dizini ile decode
cat /var/crash/*/vmcore-dmesg.txt | 
  ./scripts/decode_stacktrace.sh 
  /usr/lib/debug/boot/vmlinux-$(uname -r) 
  /usr/src/linux-source-5.15.0/

# Alternatif olarak addr2line kullan
addr2line -e /usr/lib/debug/boot/vmlinux-$(uname -r) ffffffff8105e4e1

Otomatik Analiz: sosreport ve crash-extscripts

Manuel analiz her zaman mümkün olmayabilir. Otomatik araçlar hayatı kolaylaştırır:

# RHEL/CentOS için sosreport
sudo sosreport --batch

# crash eklentileri ile otomatik rapor
crash> extend /usr/lib64/crash/extensions/
crash> help ext

# Basit bir otomasyon scripti
cat << 'EOF' > /usr/local/bin/analyze-crash.sh
#!/bin/bash
CRASHDIR=$(ls -dt /var/crash/*/ | head -1)
KERNEL=$(ls /usr/lib/debug/boot/vmlinux-* | head -1)

echo "=== CRASH ANALYSIS REPORT ===" > /tmp/crash-report.txt
echo "Date: $(date)" >> /tmp/crash-report.txt
echo "Crash dir: $CRASHDIR" >> /tmp/crash-report.txt

crash $KERNEL ${CRASHDIR}vmcore << 'CRASHCMDS' >> /tmp/crash-report.txt
log
bt
ps | grep UN
kmem -i
q
CRASHCMDS

echo "Report saved to /tmp/crash-report.txt"
cat /tmp/crash-report.txt
EOF
chmod +x /usr/local/bin/analyze-crash.sh

Debug Sembolleri Olmadan Çalışma

Bazen debug sembollerine erişimin olmayabilir. Bu durumda ne yapabilirsin?

# Ubuntu için debug sembollerini sonradan kur
sudo apt install -y linux-image-$(uname -r)-dbgsym

# Alternatif kaynak
sudo tee /etc/apt/sources.list.d/ddebs.list << EOF
deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse
EOF

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F2EDC64DC5AEE1F6B9C621F0C8CAB6595FDFF622
sudo apt update
sudo apt install linux-image-$(uname -r)-dbgsym

# RHEL/CentOS için
sudo debuginfo-install kernel-$(uname -r)

Sembollerin yüklendiğini doğrula:

# Kernel debug sembolünün varlığını kontrol et
ls /usr/lib/debug/boot/vmlinux-$(uname -r)
file /usr/lib/debug/boot/vmlinux-$(uname -r)
# Çıktı: ELF 64-bit LSB executable, x86-64, not stripped

Proaktif İzleme: Panic Olmadan Önce

Crash dump analizi önemli ama daha iyisi panic’e yol açacak durumları önceden tespit etmek:

# MCE (Machine Check Exception) hatalarını izle
sudo mcelog --client
sudo journalctl -u mcelog

# Memory hatalarını EDAC üzerinden izle
cat /sys/devices/system/edac/mc/mc0/ue_count   # Uncorrectable errors
cat /sys/devices/system/edac/mc/mc0/ce_count   # Correctable errors

# Kernel'ın kendi sağlık metriklerini izle
watch -n 5 'cat /proc/meminfo | grep -E "MemFree|Slab|KernelStack|PageTables"'

# Soft lockup uyarılarını izle
dmesg -T | grep -i "soft lockup|hung task|rcu_sched"

Bir izleme scripti hazırla:

cat << 'EOF' > /usr/local/bin/kernel-health-check.sh
#!/bin/bash
# Kernel sağlık kontrolü

ALERT=0

# Correctable memory errors kontrolü
CE_COUNT=$(cat /sys/devices/system/edac/mc/*/ce_count 2>/dev/null | awk '{sum+=$1} END{print sum+0}')
if [ "$CE_COUNT" -gt 100 ]; then
  echo "UYARI: Yüksek correctable memory error sayısı: $CE_COUNT"
  ALERT=1
fi

# Hung task kontrolü
if dmesg -T --since "1 hour ago" | grep -q "hung_task|soft lockup"; then
  echo "UYARI: Son 1 saatte hung task veya soft lockup tespit edildi!"
  ALERT=1
fi

# Disk I/O error kontrolü
if dmesg -T --since "1 hour ago" | grep -qiE "i/o error|ata.*error"; then
  echo "UYARI: Disk I/O hataları mevcut!"
  ALERT=1
fi

if [ "$ALERT" -eq 0 ]; then
  echo "Kernel sağlık durumu: OK"
fi
EOF
chmod +x /usr/local/bin/kernel-health-check.sh

# Cron'a ekle (her saat)
echo "0 * * * * root /usr/local/bin/kernel-health-check.sh | logger -t kernel-health" >> /etc/cron.d/kernel-health

Sık Karşılaşılan Hata Mesajları ve Anlamları

Kernel panic mesajlarını okumak başlı başına bir beceri. İşte sık gördüklerin:

  • “not syncing: VFS: Unable to mount root fs”: Boot sırasında root filesystem bulunamadı. initramfs bozulmuş veya disk sürücüsü yüklenemiyor olabilir.
  • “not syncing: Fatal exception in interrupt”: Interrupt handler içinde kritik hata. Genellikle donanım sürücüsü kaynaklı.
  • “not syncing: stack-protector: Kernel stack is corrupted”: Stack buffer overflow, muhtemelen kernel modülünde bug.
  • “Attempted to kill init!”: PID 1 (systemd/init) öldürüldü. Ciddi sistem bozulması.
  • “BUG: soft lockup – CPU#X stuck for Xs!”: CPU çok uzun süre interrupt disable durumunda kaldı. Sonsuz döngü veya deadlock.
  • “kernel BUG at mm/slub.c”: SLAB allocator bozulması. Genellikle use-after-free veya double-free kaynaklı.
  • “general protection fault”: Geçersiz bellek erişimi, muhtemelen bozuk pointer.

Crash Dump Saklama ve Güvenlik

Crash dump’lar sistem belleğinin anlık görüntüsüdür. İçinde şifreler, kriptografik anahtarlar ve hassas veriler bulunabilir:

# Dump dizini için kısıtlı izinler ayarla
chmod 700 /var/crash
chown root:root /var/crash

# Eski dump'ları otomatik temizle
cat << 'EOF' > /etc/cron.weekly/cleanup-crash-dumps
#!/bin/bash
# 30 günden eski dump'ları sil
find /var/crash -type d -mtime +30 -exec rm -rf {} + 2>/dev/null
# Toplam boyutu 10GB ile sınırla
du -sh /var/crash
EOF
chmod +x /etc/cron.weekly/cleanup-crash-dumps

# kdump yapılandırmasında dump sayısını sınırla
echo 'KDUMP_NUM_DUMPS=3' >> /etc/default/kdump-tools

Sonuç

Kernel panic analizi, ilk bakışta karmaşık görünen ama sistematik bir yaklaşımla oldukça çözülebilir bir alan. Önemli olan şu sırayı takip etmek:

Önce kdump’ı kur ve test et. Bir panic anında dump olmadan analiz yapamazsın ve bu kurulumu o an yapmaya çalışmak mümkün değil. Sonra vmcore-dmesg.txt ile başla, bu dosya genellikle neyin yanlış gittiğine dair ilk ipuçlarını verir. Daha derin analiz için crash aracını öğren ve özellikle bt, log, ps komutlarıyla rahat hale gel.

Gerçek dünyada karşılaştığım vakaların büyük çoğunluğu üç kategoriye düşüyor: bozuk RAM (mcelog çalıştır, memtest yap), hatalı kernel modülleri (tainted flag’e bak, son yüklenen modülleri incele) ve disk arızaları (I/O error mesajlarına bak, SMART verilerini kontrol et). Bu üçünü iyi araştırırsan vakaların yüzde seksenini çözersin.

Son olarak şunu söyleyeyim: crash dump analizi bir kez öğrendiğinde artık kernel panic seni korkutmaz. Hatta biraz “en azından ne olduğunu bileceğim” düşüncesiyle rahatlamaya başlarsın. Bu pek sağlıklı bir ruh hali olmayabilir ama sysadmin’liğin doğası zaten böyle.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir