coredumpctl Komutu ile Linux’ta Çökme Dökümlerini İnceleme ve Hata Analizi Yapma

Yazar:komut.io ekibi Süreç ve Sistem İzleme Komutları
0 Yorum

Bir gece yarısı alarmı aldınız: üretim sunucusundaki kritik bir servis defalarca çöküyor, sistem log’ları belirsiz mesajlar veriyor ve siz de neyin yanlış gittiğini anlamaya çalışıyorsunuz. İşte tam bu anda coredumpctl sizin en iyi arkadaşınız haline geliyor. Yıllar önce bu tür senaryolarda elimizde sadece dmesg çıktıları ve yarım yamalak log dosyaları vardı. Systemd ekosisteminin bize kazandırdığı coredumpctl, çökme analizini bambaşka bir seviyeye taşıdı.

coredumpctl Nedir ve Neden Önemlidir?

coredumpctl, systemd’nin systemd-coredump servisiyle entegre çalışan bir komut satırı aracıdır. Temel işlevi, süreçlerin çökmesi sırasında oluşturulan core dump dosyalarını yönetmek ve analiz etmektir. Eski yöntemde core dosyaları /tmp altına saçılırdı, bazı dağıtımlarda ulimit ayarları yanlış yapılandırıldığında hiç oluşmazdı bile. Şimdi ise systemd-coredump bu dosyaları journal‘a veya /var/lib/systemd/coredump/ dizinine düzenli biçimde kaydediyor, metadata ile zenginleştiriyor.

Peki bu neden bu kadar değerli? Çünkü çökme anında programın tam bellek durumunu, çağrı yığınını (call stack), kayıt defterlerini (registers) ve çok daha fazlasını yakalıyorsunuz. Bu bilgiler olmadan bir segmentation fault’u debug etmek, karanlıkta el yordamıyla yürümek gibidir.

Kurulum ve Ön Koşullar

Çoğu modern dağıtımda systemd-coredump zaten kurulu gelir ama kontrol etmek iyi alışkanlıktır.

# systemd-coredump servisinin kurulu olup olmadığını kontrol edin
systemctl status systemd-coredump.socket

# Debian/Ubuntu tabanlı sistemlerde eksikse
sudo apt install systemd-coredump

# RHEL/CentOS/Rocky Linux için
sudo dnf install systemd-coredump

# coredumpctl aracının sürümünü kontrol edin
coredumpctl --version

Bir de /proc/sys/kernel/core_pattern ayarına bakmak gerekiyor. Eğer bu değer |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h gibi bir şeye işaret etmiyorsa, sistem dump’ları systemd’ye yönlendirmiyor demektir.

# Mevcut core pattern'i görüntüleyin
cat /proc/sys/kernel/core_pattern

# Doğru yapılandırma için
sudo sysctl -w kernel.core_pattern="|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h"

# Kalıcı hale getirmek için /etc/sysctl.d/50-coredump.conf dosyasına ekleyin
echo "kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" | sudo tee /etc/sysctl.d/50-coredump.conf

Temel Kullanım: Kayıtlı Dump’ları Listeleme

Sisteme girdikten sonra ilk yapacağınız iş mevcut core dump kayıtlarına bakmak olacak.

# Tüm kayıtlı core dump'ları listele
coredumpctl list

# Belirli bir zaman aralığındaki dump'ları filtrele
coredumpctl list --since="2024-01-15" --until="2024-01-16"

# Sadece belirli bir binary'e ait dump'ları göster
coredumpctl list nginx

# Son 10 dump'ı listele
coredumpctl list -n 10

# Çıktıyı daha ayrıntılı görmek için
coredumpctl list --no-pager

list komutu size şu bilgileri verir: zaman damgası, PID, UID, GID, sinyal (hangi sinyal çökmeye yol açtı), corefile durumu ve binary adı. SIGNAL sütunu özellikle dikkat etmeniz gereken yer; SIGSEGV (11), SIGABRT (6), SIGBUS (7) gibi sinyaller farklı sorun kategorilerine işaret eder.

Dump Detaylarını İnceleme

Bir çökmeyi listeledikten sonra detaylarına inmek için info alt komutunu kullanırsınız.

# En son çökmenin bilgilerini göster
coredumpctl info

# Belirli bir PID'e ait çökme bilgisi
coredumpctl info 47823

# Belirli bir binary'in son çökmesini incele
coredumpctl info nginx

# Çökme bilgisini bir dosyaya kaydet
coredumpctl info 47823 > crash_report_47823.txt

info çıktısında dikkat etmeniz gereken alanlar şunlardır:

  • Signal: Çökmeye neden olan sinyal numarası ve adı
  • Command Line: Çöken sürecin tam komut satırı
  • Executable: Binary’nin tam yolu
  • Control Group: Hangi cgroup’a ait olduğu (container içindeyse belli olur)
  • Storage: Core dump’ın nerede saklandığı
  • Stack Trace: Kısmi yığın izi (tam analiz için GDB gerekir)

GDB ile Derin Analiz

coredumpctl‘ın en güçlü özelliklerinden biri, core dump’ı doğrudan GDB’ye (GNU Debugger) besleyebilmesidir. Debug sembolleri yüklüyse bu özellik inanılmaz derecede değerli hale gelir.

# Core dump'ı GDB'de aç
coredumpctl gdb

# Belirli bir PID için
coredumpctl gdb 47823

# Belirli bir binary için
coredumpctl gdb /usr/bin/nginx

GDB açıldıktan sonra kullanabileceğiniz bazı temel komutlar:

# GDB içinde çalıştırın (# işaretleri yorum satırıdır, GDB'ye yazmayın)

# Tam yığın izini göster
bt full

# Her thread'in yığın izini göster
thread apply all bt

# Belirli bir frame'e geç
frame 3

# O frame'deki yerel değişkenleri göster
info locals

# Kayıtçı değerlerini göster
info registers

# Belirli bir bellek adresinin içeriğini göster
x/20x $rsp

Debug sembolleri olmadan GDB çıktısı oldukça kısıtlı kalır; sadece adresler görürsünüz, fonksiyon isimleri değil. Bu yüzden üretim paketleri için bile debug sembol paketlerini kurmak ciddi bir avantaj sağlar.

# Debian/Ubuntu'da debug sembolleri için
sudo apt install nginx-dbg

# RHEL/Rocky için debuginfo paketleri
sudo dnf debuginfo-install nginx

# Veya debuginfo-install aracıyla
sudo debuginfo-install $(rpm -qa --queryformat "%{NAME}n" | grep nginx)

Gerçek Dünya Senaryosu: Nginx Worker Çöküyor

Şimdi gerçeğe yakın bir senaryo üzerinden gidelim. Diyelim ki Nginx worker process’leri intermittent olarak çöküyor ve access log’larda da pek bir ipucu yok.

# Nginx ile ilgili tüm çökmeleri filtrele
coredumpctl list nginx

# Çıktı örneği:
# TIME                            PID  UID  GID SIG COREFILE  EXE
# Wed 2024-01-15 03:42:17 +03    2841 1000    0  11 present   /usr/sbin/nginx
# Wed 2024-01-15 07:15:33 +03    3102 1000    0  11 present   /usr/sbin/nginx

# En son çökmenin detaylarını incele
coredumpctl info nginx

# GDB ile derinlemesine analiz
coredumpctl gdb nginx

GDB açıldıktan sonra:

# Yığın izini al
(gdb) bt full

# Tüm thread'leri kontrol et - çok kritik!
(gdb) thread apply all bt full

# Çöküm anındaki değişkenleri incele
(gdb) frame 0
(gdb) info locals
(gdb) print *request

Bu örnek senaryoda SIGSEGV (sinyal 11) geldiği için muhtemelen bir null pointer dereference veya buffer overflow durumu söz konusu. bt full çıktısındaki fonksiyon zinciri bize tam olarak hangi modül veya third-party eklentinin sorun çıkardığını gösterecektir.

Core Dump Dosyasını Dışa Aktarma

Bazen core dump’ı başka bir sisteme taşımak veya arşivlemek isteyebilirsiniz. Bu özellikle üretim ortamında sorunu geliştirme ortamında reprodükte etmek istediğinizde işe yarar.

# Core dump'ı bir dosyaya aktar
coredumpctl dump nginx -o /tmp/nginx_core_20240115.dump

# Belirli bir PID'in dump'ını aktar
coredumpctl dump 47823 -o /var/archive/crashes/crash_47823.core

# Boyutunu kontrol et (büyük uygulamalarda GB'lara ulaşabilir!)
ls -lh /tmp/nginx_core_20240115.dump

# Dışa aktarılan core'u GDB ile analiz et (binary ile birlikte)
gdb /usr/sbin/nginx /tmp/nginx_core_20240115.dump

Önemli uyarı: Core dump dosyaları son derece hassas bilgiler içerebilir; şifreler, API anahtarları, kullanıcı verileri bellekte duruyorsa core’a da yansır. Bu dosyaları güvenli bir şekilde saklayın ve gereksiz yere paylaşmayın.

systemd-coredump Yapılandırması

/etc/systemd/coredump.conf dosyası, dump’ların nasıl yönetileceğini kontrol eder. Bu dosyayı bilmeden üretim sisteminde çalışmak pek sağlıklı olmaz.

# Mevcut yapılandırmayı görüntüle
cat /etc/systemd/coredump.conf

# Örnek yapılandırma içeriği:
# [Coredump]
# Storage=external
# Compress=yes
# ProcessSizeMax=2G
# ExternalSizeMax=2G
# JournalSizeMax=767M
# MaxUse=
# KeepFree=

Önemli parametreler:

  • Storage=external: Dump’ları /var/lib/systemd/coredump/ altına yazar; journal seçeneği doğrudan journal’a gömer
  • Compress=yes: LZ4 ile sıkıştırma yapar, disk tasarrufu sağlar
  • ProcessSizeMax: Dump alınacak maksimum process boyutu; büyük Java veya .NET süreçleri için artırmanız gerekebilir
  • MaxUse: Dump’lar için ayrılacak maksimum disk alanı
# Yapılandırmayı değiştirdikten sonra servisi yeniden yükle
sudo systemctl daemon-reload
sudo systemctl restart systemd-coredump.socket

Journal’dan Çökme Logları

coredumpctl sadece core dump’ları değil, journal kayıtlarıyla da entegre çalışır. Çökme anında sistemde tam olarak ne olduğunu anlamak için bu entegrasyon çok değerlidir.

# Belirli bir PID'in çökmesinden önceki ve sonraki journal kayıtları
journalctl _PID=47823

# Belirli bir zaman dilimindeki çökmelerle ilgili tüm loglar
journalctl --since="2024-01-15 03:40:00" --until="2024-01-15 03:45:00" -p err

# Kernel mesajlarıyla birlikte
journalctl -k --since="2024-01-15 03:40:00"

# Belirli bir servisin çökmesinden önceki 50 satır
journalctl -u nginx.service -n 50 --no-pager

İleri Düzey: Python Script ile Otomatik Çökme Raporu

Büyük ortamlarda her çökme için manuel analiz yapmanız imkansız. Aşağıdaki basit script, yeni çökmeleri tespit edip mail veya Slack’e gönderebilecek bir yapının temelini oluşturabilir.

#!/bin/bash
# crash_monitor.sh - Yeni çökmeleri tespit ve raporla

REPORT_DIR="/var/log/crash_reports"
LAST_CHECK_FILE="/var/run/crash_monitor_last"
mkdir -p "$REPORT_DIR"

# Son kontrol zamanından bu yana yeni çökme var mı?
if [ -f "$LAST_CHECK_FILE" ]; then
    LAST_CHECK=$(cat "$LAST_CHECK_FILE")
    NEW_CRASHES=$(coredumpctl list --since="$LAST_CHECK" --no-pager 2>/dev/null | tail -n +2 | wc -l)
else
    NEW_CRASHES=$(coredumpctl list --since="1 hour ago" --no-pager 2>/dev/null | tail -n +2 | wc -l)
fi

if [ "$NEW_CRASHES" -gt 0 ]; then
    REPORT_FILE="$REPORT_DIR/crash_$(date +%Y%m%d_%H%M%S).txt"
    echo "=== CRASH REPORT - $(date) ===" > "$REPORT_FILE"
    echo "Yeni çökme sayısı: $NEW_CRASHES" >> "$REPORT_FILE"
    echo "" >> "$REPORT_FILE"
    coredumpctl list --since="${LAST_CHECK:-1 hour ago}" --no-pager >> "$REPORT_FILE"
    echo "" >> "$REPORT_FILE"
    echo "=== DETAYLAR ===" >> "$REPORT_FILE"
    coredumpctl info --since="${LAST_CHECK:-1 hour ago}" >> "$REPORT_FILE"

    # Opsiyonel: mail veya webhook ile gonder
    # mail -s "UYARI: $NEW_CRASHES yeni çökme tespit edildi" [email protected] < "$REPORT_FILE"
    
    echo "Rapor oluşturuldu: $REPORT_FILE"
fi

date --iso-8601=seconds > "$LAST_CHECK_FILE"

Bu scripti cron’a ekleyerek periyodik kontrol sağlayabilirsiniz:

# Her 15 dakikada bir kontrol
*/15 * * * * /usr/local/bin/crash_monitor.sh

Container ve Kubernetes Ortamlarında Kullanım

Modern altyapılarda container içindeki çökmeleri yakalamak ayrı bir meydan okuma. Docker veya Podman container’larında süreçler çöktüğünde core dump’lar host sistemin systemd-coredump‘ına düşebilir; bu container’ın PID namespace’ine bağlıdır.

# Container içindeki bir sürecin host üzerindeki PID'ini bul
docker inspect --format '{{.State.Pid}}' container_adi

# O PID'e ait çökme kaydı var mı?
coredumpctl list | grep <host_pid>

# Kubernetes ortamında node üzerinde doğrudan kontrol
kubectl debug node/node-01 -it --image=ubuntu
# Node shell'inde:
chroot /host
coredumpctl list

Kubernetes ortamında core_pattern‘i DaemonSet ile yönetmek yaygın bir pratiktir; her node’da aynı yapılandırmanın olduğundan emin olmak için bu yaklaşım güvenilir sonuç verir.

Sık Karşılaşılan Sorunlar ve Çözümleri

“No coredumps found” hatası alıyorsunuz:

# ulimit değerlerini kontrol edin
ulimit -c

# 0 çıkıyorsa core dump devre dışı
# /etc/security/limits.conf veya systemd servis dosyasına ekleyin:
# * soft core unlimited
# Veya servis biriminde:
# LimitCORE=infinity

# systemd servis dosyasına core dump izni verin
sudo systemctl edit nginx.service
# Eklenecek satır:
# [Service]
# LimitCORE=infinity

Core dosyaları çok yer kaplıyor:

# Eski dump'ları temizle (30 günden eski)
sudo coredumpctl clean --until="30 days ago"

# Manuel temizlik
sudo rm /var/lib/systemd/coredump/*.lz4

# Disk kullanımını kontrol et
du -sh /var/lib/systemd/coredump/

Debug sembolleri yüklü değil:

# Fedora/RHEL için debuginfod servisini kullan
export DEBUGINFOD_URLS="https://debuginfod.fedoraproject.org"
coredumpctl gdb nginx
# GDB otomatik olarak sembol indirecektir

Sonuç

coredumpctl, sistemde yaşanan çökmeleri rastgele log satırlarına bakarak anlamaya çalışmak yerine doğrudan çöküm anının fotoğrafını incelemenizi sağlıyor. Yıllar içinde öğrendiğim en önemli şey şu: sorun analizi için erken hazırlık yapmak, gece yarısı paniğini büyük ölçüde azaltıyor. Tüm servislerinizde LimitCORE=infinity ayarını yapın, debug sembol paketlerini kurun, crash_monitor.sh gibi bir izleme mekanizması kurun; o gece yarısı alarmı geldiğinde elinizin altında tüm veriler hazır olsun.

coredumpctl + GDB + journalctl üçlüsü, Linux sistem yöneticisinin en güçlü hata ayıklama zincirini oluşturuyor. Bu araçları günlük iş akışınıza entegre etmek, sizi reaktif bir sorun çözücüden proaktif bir sistem uzmanına dönüştürüyor. Ve unutmayın: iyi bir sysadmin sorunu çözen değil, sorunun tekrar yaşanmasını önleyen kişidir.

Bir yanıt yazın

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