/proc/sysrq-trigger ile Donmuş Linux Sistemlerinde Acil Müdahale ve Güvenli Yeniden Başlatma

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

Geceleri uyku uyuyamadığınız o anları bilirsiniz: monitoring sistemi alarm veriyor, SSH bağlantısı yanıt vermiyor, konsola geçiyorsunuz ama ekran donmuş durumda. Sunucuyu fiziksel olarak kapatıp açmaktan başka çareniz yok gibi görünüyor. İşte tam bu noktada SysRq mekanizması devreye giriyor ve o “kapı açık mı acaba?” hissini yaşatıyor.

SysRq (System Request), Linux çekirdeğine doğrudan komut göndermenizi sağlayan bir araç. Kullanıcı alanı tamamen çökmüş, init sistemi yanıt vermez hale gelmiş, hatta bash bile açılmıyorken bile çekirdek ile konuşabiliyorsunuz. Bu yazıda hem teorik altyapısını hem de gerçek acil senaryolardaki kullanımını ele alacağız.

SysRq Nedir ve Neden Var?

Linux çekirdeği, acil durumlar için özel bir kanal bırakmış: /proc/sysrq-trigger. Bu dosyaya tek bir karakter yazarak çekirdeğe doğrudan talimat gönderebilirsiniz. Bunun güzel tarafı şu: OOM killer devreye girmemiş, init sistemi askıda kalmış, hatta kill komutu bile çalışmıyor olsa bile bu mekanizma çoğunlukla işe yarıyor.

Fiziksel sunucularda klavye üzerinden de kullanılabiliyor. Alt+SysRq+[tuş] kombinasyonuyla. Ama biz sysadminler genellikle remote ortamlarda çalışıyoruz. Dolayısıyla /proc/sysrq-trigger dosyası bizim için çok daha kritik.

Önce şunu kontrol edelim, sistemde SysRq aktif mi:

cat /proc/sys/kernel/sysrq

Dönen değerler şunlar olabilir:

  • 0: Tamamen devre dışı
  • 1: Tüm SysRq fonksiyonları aktif
  • 2: Sadece konsol log seviyesi kontrolü aktif
  • 4: Klavye kontrolü (SAK, unraw)
  • 8: Süreç dump etme aktif
  • 16: Sync işlemi aktif
  • 32: Remount read-only aktif
  • 64: Sinyal gönderme (kill) aktif
  • 128: Reboot ve shutdown aktif
  • 256: OOM killer kontrolü aktif

Bu değerler bitwise OR ile birleştiriliyor. Yani 176 değeri (16+32+128) gördüğünüzde sync, remount-ro ve reboot aktif demek.

SysRq’yu Aktif Etmek

Production sunucularında SysRq genellikle kapalı geliyor ya da kısıtlı. İlk yapmanız gereken şey bunu aktif etmek:

# Geçici olarak aktif etmek (yeniden başlatmada sıfırlanır)
echo 1 > /proc/sys/kernel/sysrq

# Veya sysctl üzerinden
sysctl -w kernel.sysrq=1

# Kalıcı hale getirmek için
echo "kernel.sysrq = 1" >> /etc/sysctl.conf
sysctl -p

Peki production’da her şeyi açmak ne kadar güvenli? Bu tartışmalı bir konu. Ben genellikle şu yaklaşımı benimsiyorum: kritik sistemlerde 176 değerini kullanıyorum. Yani sync + remount-ro + reboot. OOM killer müdahalesini ve süreç dump etmeyi kapatık tutuyorum çünkü bunlar yanlış ellerde sıkıntı yaratabilir.

# Dengeli bir production ayarı
sysctl -w kernel.sysrq=176

Temel SysRq Komutları

/proc/sysrq-trigger dosyasına yazabileceğiniz karakterler ve ne işe yaradıkları:

  • b: Sync veya unmount yapmadan anında yeniden başlatır. En agresif seçenek, son çare.
  • c: Kasıtlı olarak kernel panic tetikler. Kdump/kexec aktifse memory dump alır.
  • d: Tutulan tüm lock’ları listeler.
  • e: init dışındaki tüm süreçlere SIGTERM gönderir.
  • f: OOM killer’ı tetikler, en fazla bellek kullanan süreci öldürür.
  • g: Kgdb için kullanılır (kernel debugger).
  • h: SysRq yardım mesajını kernel log’a yazar.
  • i: init dışındaki tüm süreçlere SIGKILL gönderir.
  • j: “Just thaw it” – FIFREEZE ile dondurulmuş filesystem’leri çözer.
  • k: SAK (Secure Access Key) – mevcut terminaldeki tüm programları öldürür.
  • l: Tüm CPU’lardaki stack trace’leri gösterir.
  • m: Mevcut bellek bilgisini kernel log’a döker.
  • n: RT süreçlerinin nice değerini ayarlar.
  • o: Sistemi kapatır (shutdown).
  • p: Mevcut register ve flag değerlerini döker.
  • q: Timer ile ilgili bilgileri döker.
  • r: Klavyeyi raw moddan çıkarır (X11 çöktükten sonra kullanışlı).
  • s: Tüm bağlı filesystem’leri sync eder. Kritik!
  • t: Tüm mevcut task’ların bilgisini döker.
  • u: Tüm filesystem’leri read-only olarak remount eder. Kritik!
  • v: Framebuffer konsolu geri yükler.
  • w: Uninterruptible sleep’teki süreçleri listeler.
  • x: xmon interface’i (PowerPC’de).
  • z: Ftrace buffer’ını döker.
  • 0-9: Konsol log seviyesini ayarlar.

REISUB: Donmuş Sistemi Güvenle Kapatmanın Şifresi

Gerçek dünyada en sık kullanılan kombinasyon REISUB. Bu sırayı bir kere öğrendiniz mi bir daha unutmayacaksınız. Ben bunu “Rusya Ele Işkence Sürüyorsa Uyku Bul” diye ezberlemiştim, ama siz kendi mnemonik’inizi bulun.

  • R: Klavyeyi raw moddan çıkar
  • E: SIGTERM gönder (init hariç)
  • I: SIGKILL gönder (init hariç, E’den sonra hala ayaktaysa)
  • S: Filesystem sync et
  • U: Unmount/read-only yap
  • B: Reboot

Her adım arasında birkaç saniye beklemek önemli. Özellikle E ile I arasında ve S ile U arasında:

# Komut satırından REISUB uygulamak
# Her komut arasında 2-3 saniye bekleyin

echo r > /proc/sysrq-trigger
sleep 2
echo e > /proc/sysrq-trigger
sleep 5
echo i > /proc/sysrq-trigger
sleep 2
echo s > /proc/sysrq-trigger
sleep 3
echo u > /proc/sysrq-trigger
sleep 2
echo b > /proc/sysrq-trigger

Bunu bir script haline getirebilirsiniz ama dikkatli olun: bu script sonunda sunucunuz yeniden başlıyor. Üretim ortamında çalıştırmadan önce iki kez düşünün.

#!/bin/bash
# emergency_reboot.sh - Güvenli Acil Yeniden Başlatma

SYSRQ="/proc/sysrq-trigger"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a /var/log/emergency_reboot.log
}

if [ "$(id -u)" != "0" ]; then
    echo "Bu script root yetkisi gerektirir."
    exit 1
fi

log "Acil yeniden başlatma prosedürü başlatılıyor..."

log "Adım 1: Klavye raw moddan çıkarılıyor (R)"
echo r > $SYSRQ
sleep 2

log "Adım 2: SIGTERM tüm süreçlere gönderiliyor (E)"
echo e > $SYSRQ
sleep 5

log "Adım 3: SIGKILL tüm süreçlere gönderiliyor (I)"
echo i > $SYSRQ
sleep 3

log "Adım 4: Filesystem sync ediliyor (S)"
echo s > $SYSRQ
sleep 4

log "Adım 5: Filesystem read-only yapılıyor (U)"
echo u > $SYSRQ
sleep 3

log "Adım 6: Yeniden başlatılıyor (B)"
echo b > $SYSRQ

Gerçek Dünya Senaryoları

Senaryo 1: OOM Felaketi

Sabah 3’te alarm geliyor. Bir Java uygulaması belleği yedi bitirdi, kernel OOM killer devreye girdi ama yeterli olmadı. SSH bağlantısı inanılmaz yavaş, komutlar 30 saniyede bir yanıt veriyor. Sistemde hala aktif veritabanı bağlantıları var, verileri korumak zorundasınız.

# Önce mevcut durumu anlamaya çalış
# SSH bağlantısı geliyorsa dmesg'e bak
dmesg | tail -50

# OOM durumunu kontrol et
grep -i "oom|killed process" /var/log/kern.log | tail -20

# Eğer hala müdahale şansın varsa, problemi yaratan süreci öldür
# ve sistemi kurtarmaya çalış
echo f > /proc/sysrq-trigger  # OOM killer'ı manuel tetikle

# Durum iyileşmiyorsa sync ve reboot
echo s > /proc/sysrq-trigger
sleep 5
echo u > /proc/sysrq-trigger
sleep 3
echo b > /proc/sysrq-trigger

Senaryo 2: Zombie Süreç Salgını

Fork bomb ya da yanlış yazılmış bir uygulama binlerce zombie süreç oluşturdu. PID tablosu doldu, yeni süreç başlatamıyorsunuz. kill komutu bile açılamıyor çünkü yeni process fork edilemiyor.

# SysRq üzerinden tüm süreçlere SIGTERM
echo e > /proc/sysrq-trigger
sleep 10

# Hala sorun varsa SIGKILL
echo i > /proc/sysrq-trigger
sleep 5

# Temiz kapanış
echo s > /proc/sysrq-trigger
sleep 3
echo u > /proc/sysrq-trigger
sleep 2
echo b > /proc/sysrq-trigger

Senaryo 3: Filesystem’in Kilitlenmesi

NFS mount noktası yanıt vermiyor ve bu yüzden o dosyalarla işi olan tüm süreçler uninterruptible sleep’e girdi. D state’indeki bu süreçleri normal yollarla öldürmek mümkün değil.

# Önce durumu tespit et
echo w > /proc/sysrq-trigger
# dmesg veya /var/log/kern.log'da hangi süreçlerin D state'te olduğunu gör

# Eğer dondurulmuş filesystem varsa önce çözmeyi dene
echo j > /proc/sysrq-trigger

# Sorun devam ediyorsa
echo s > /proc/sysrq-trigger
sleep 5
echo u > /proc/sysrq-trigger
sleep 3
echo b > /proc/sysrq-trigger

Senaryo 4: X11 veya Wayland Çöktü, Konsola Dönmek İstiyorsunuz

Bu daha az kritik ama sinir bozucu bir durum. Masaüstü ortamı tamamen dondu, Alt+F2 gibi kombinasyonlar işe yaramıyor.

# Klavyeyi X11'in etkisinden kurtar
echo r > /proc/sysrq-trigger

# Artık Ctrl+Alt+F1/F2 gibi kombinasyonlar çalışmalı
# Sanal terminale geçip X11'i düzgün kapatabilirsiniz

Kdump ile Birlikte Kullanım: Crash Analizi

Bir sistem çöktüğünde sadece yeniden başlatmak yetmez, neyin çöktüğünü anlamak gerekir. Kdump + SysRq kombinasyonu tam burada devreye giriyor.

# Önce kdump kurulumu (RHEL/CentOS)
yum install kexec-tools
systemctl enable --now kdump

# Crash tetiklemek için (sadece test ortamında!)
echo c > /proc/sysrq-trigger

# Crash dump /var/crash altında oluşur
ls -la /var/crash/

# crash utility ile analiz
crash /var/crash/[timestamp]/vmcore /usr/lib/debug/lib/modules/$(uname -r)/vmlinux

SysRq’yu Monitoring ile Entegre Etmek

Bazı ekipler SysRq kullanımını otomatize ediyor. Bu riskli bir yaklaşım ama doğru şartlarda mantıklı olabilir. Örneğin, belirli bir eşiği geçen bellek kullanımında otomatik sync tetiklemek:

#!/bin/bash
# memory_watchdog.sh

THRESHOLD=95
SYSRQ="/proc/sysrq-trigger"
LOG="/var/log/memory_watchdog.log"

while true; do
    MEM_USED=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')

    if [ "$MEM_USED" -gt "$THRESHOLD" ]; then
        echo "[$(date)] UYARI: Bellek kullanımı %${MEM_USED}. Sync tetikleniyor." >> $LOG
        echo s > $SYSRQ

        # Burada alert gönderebilir, log yazabilirsiniz
        # Otomatik reboot eklemek çok riskli - manuel müdahale tercih edin
    fi

    sleep 30
done

Güvenlik Konuları

SysRq güçlü bir araç ve bu güç beraberinde risk getiriyor. Production ortamda dikkat edilmesi gerekenler:

Öncelikle, SysRq’ya erişim kontrolü yapın. /proc/sys/kernel/sysrq dosyasına yazma yetkisi olan herkes sistemi yeniden başlatabilir. SELinux veya AppArmor politikalarınız bunu sınırlandırabilir.

# SELinux ile SysRq erişimini kontrol etmek
getsebool -a | grep sysrq

# Audit log ile SysRq kullanımını izlemek
auditctl -w /proc/sysrq-trigger -p w -k sysrq_usage

İkinci olarak, hangi özelliklerin aktif olduğunu minimize edin. Tüm özelliklere ihtiyacınız yoksa sadece ihtiyaç duyduklarınızı açın:

# Sadece sync (16) + remount-ro (32) + reboot (128) = 176
echo "kernel.sysrq = 176" >> /etc/sysctl.d/99-sysrq.conf
sysctl --system

Üçüncüsü, IPMI veya iDRAC gibi out-of-band yönetim araçlarınız varsa bunları da değerlendirin. SysRq tek çözüm değil, ama en erişilebilir olanı.

dmesg ve Kernel Log Okuma

SysRq komutlarının çıktıları kernel log’a yazılır. Bu log’ları okumak için:

# Anlık kernel log
dmesg -T | tail -100

# dmesg'i sürekli izlemek için
dmesg -w

# Kernel log'u dosyaya yazmak
dmesg -T > /tmp/kernel_$(date +%Y%m%d_%H%M%S).log

# SysRq ile tetiklenen olayları filtrelemek
dmesg -T | grep -i "sysrq|OOM|killed"

Eğer sistem donmuşsa ve console üzerinden bağlıysa serial console üzerinden de çalışabilirsiniz. Bu tamamen ayrı bir konu ama SysRq ile birlikte kullanıldığında inanılmaz güçlü bir kombinasyon.

Alternatif: Magic SysRq Olmadan Ne Yapılabilir?

Bazen SysRq de çalışmaz. O zaman elinizdeki seçenekler:

  • IPMI/iDRAC/iLO üzerinden hard reset: Donanım seviyesinde müdahale
  • Watchdog daemon: watchdog servisi konfigüre edilmişse sistem kendini yeniden başlatır
  • kdump’tan sonra otomatik boot: Kernel panic sonrası otomatik recovery
# Hardware watchdog kontrolü
ls /dev/watchdog*

# Watchdog servisini kontrol et
systemctl status watchdog

# Watchdog timeout değerini görüntüle
cat /sys/class/watchdog/watchdog0/timeout

Sonuç

SysRq mekanizması, Linux’un kriz anlarındaki son savunma hattı. Bunu bir “break glass” araç olarak düşünebilirsiniz: normalde kullanmazsınız ama tam olarak ihtiyaç duyduğunuz anda hayat kurtarır.

Öğrendiklerinizi pratiğe dökmek için test ortamında deneyim kazanmanızı şiddetle tavsiye ederim. Sanal bir makineye REISUB uygulamak, gerçek acil durumda paniksiz hareket etmenizi sağlar. Kaslarınız bu komutları hatırlasın ki 3’te gelen arama sizi şaşkına çevirmesin.

Production sistemlerde SysRq’yu aktif etmek bir kararname değil, bilinçli bir tercih olmalı. Hangi özelliklere ihtiyacınız var, güvenlik riskleri neler, audit log tutuyor musunuz? Bu soruları yanıtlamadan 1 yazıp geçmeyin.

Son olarak: REISUB sırasını ezberleyin. Klavyede değil, /proc/sysrq-trigger üzerinden de olsa bu sıra değişmiyor. R-E-I-S-U-B. Veri kaybetmeden sistemi kurtarmanın en temiz yolu bu sırayı doğru ve zamanında uygulamaktan geçiyor.

Bir yanıt yazın

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