Sunucuda Kernel Panic: Kök Neden ve Kurtarma

VPS ya da fiziksel sunucunuz bir anda yeniden başladıysa ve SSH bağlantısı artık kurulmuyorsa, ilk hedefiniz servisi rastgele yeniden başlatmak değil, sistemin hangi aşamada durduğunu belirlemektir. Ekranda Kernel panic, Unable to mount root fs, Out of memory veya benzeri bir hata görmeniz, Linux çekirdeğinin normal çalışmayı güvenli bulmadığı için durduğunu gösterebilir.

Kernel panic bir kök neden değil, çekirdeğin devam edemediği kritik bir durumdur. Hatalı veya uyumsuz bir modül, bozuk dosya sistemi, erişilemeyen kök disk, arızalı bellek, firmware sorunu, hatalı çekirdek güncellemesi ve bazı sanallaştırma katmanı problemleri aynı belirtiyi üretebilir. Bu nedenle Linux kernel panic çözümü, tek bir komuttan çok kontrollü bir teşhis akışıdır.

Kernel panic nasıl anlaşılır?

Normal bir uygulama hatasında bir süreç kapanır; sistemin geri kalanı çalışmaya devam eder. Kernel panic durumunda ise çekirdek, donanım veya temel sistem kaynaklarıyla güvenli biçimde iletişim kuramadığı için sistemi durdurabilir. Yapılandırmaya bağlı olarak sunucu ekranda hata mesajı bırakır, otomatik yeniden başlar veya donmuş gibi görünür.

Şu belirtiler aynı olayı farklı biçimlerde gösterebilir:

• SSH ve diğer ağ servisleri aynı anda erişilemez hale gelir.
• İzleme sistemi kısa aralıklarla yeniden başlama bildirimi gönderir.
• Sunucu sağlayıcısının konsolunda kernel panic, stack trace veya not syncing ifadesi görülür.
• Yeniden başlatma sonrasında kök dosya sistemi bağlanamaz veya sunucu acil durum kabuğuna düşer.
• Makine yalnızca belirli çekirdek sürümünde açılır ya da yük altında tekrar kapanır.

Tek başına SSH kesintisi kernel panic kanıtı değildir. Ağ yapılandırması, güvenlik duvarı, dolu disk, servis kilitlenmesi veya sağlayıcı tarafındaki sanal makine olayı da benzer bir dış belirti oluşturabilir. Önce konsoldan görüntü almanız ve sağlayıcı panelindeki yeniden başlatma zamanını not etmeniz bu ayrımı yapmanızı sağlar.

İlk müdahale: erişimi ve kanıtı güvenceye alın

Konsol erişimini kullanın

SSH çalışmadığında web konsolu, sanal seri konsol, KVM, iKVM veya fiziksel ekran üzerinden bağlanın. Bu erişim yolları işletim sisteminin ağ servislerine bağlı olmadığı için teşhisi sürdürmenize yardımcı olur. VPS kullanıyorsanız konsolun sağlayıcı panelinde nasıl etkinleştirildiğini ve ekran çıktısının nasıl alınacağını önceden doğrulayın.

Önce ekrandaki panic mesajının tamamını kaydedin. Özellikle Call Trace, RIP, Oops, modül adı, disk aygıtı, UUID, dosya sistemi ve çekirdek sürümü gibi bölümler önemlidir. Bir satırda geçen modül adı her zaman hatanın kesin nedeni değildir; çağrı zincirinde görünen son bileşen olabilir.

Olayı zaman çizelgesine yerleştirin

Şu bilgileri aynı zaman aralığında karşılaştırın:

• İlk erişim kesintisinin UTC veya yerel saat karşılığı.
• Sağlayıcı panelindeki güç döngüsü, taşıma, bakım veya sanal makine olayı.
• Son kernel, firmware, sürücü, depolama veya güvenlik güncellemesi.
• Trafik, disk kullanımı, bellek tüketimi ve sıcaklıkta olağandışı değişim.
• Planlı cron işleri, yedekleme, büyük dosya işlemleri veya yoğun derleme süreçleri.

Bu zaman çizelgesi, örneğin çekirdek güncellemesinden hemen sonra başlayan bir önyükleme sorununu, haftalardır yük altında ortaya çıkan bellek arızasından ayırmanıza yardım eder. Sistem tekrar açılabiliyorsa, değişiklik yapmadan önce temel kayıtları dışarı aktarın.

Önyükleme sonrasında logları inceleyin

Sunucu eski bir çekirdekle veya geçici bir kurtarma seçeneğiyle açıldıysa, ilk işiniz son başarısız açılışa ait kayıtları aramaktır. journalctl yalnızca systemd journal tutuluyorsa işe yarar. Journal kalıcı değilse, ani güç kesintisi veya panic sonrasında önceki açılışa ait kayıtların bir bölümü kaybolabilir.

journalctl --list-boots
journalctl -b -1 -k --no-pager
journalctl -b -1 -p err..alert --no-pager
uname -a
cat /proc/cmdline

-b -1 önceki açılışı, -k yalnızca kernel kayıtlarını, -p err..alert ise hata ve daha yüksek öncelikli kayıtları seçer. Önceki boot görünmüyorsa bunu “kayıt yok, sorun yok” şeklinde yorumlamayın. Kalıcı journal yapılandırılmamış olabilir veya panic kayıtları yalnızca konsola yazılmış olabilir.

Journal kalıcılığını kontrol etmek için mevcut dizine bakabilirsiniz:

test -d /var/log/journal && echo "Kalıcı journal dizini var" || echo "Kalıcı journal dizini yok"
findmnt /var
findmnt /

Bu komutlar yalnızca durum tespiti yapar. Journal kalıcılığını sonradan etkinleştirmek gelecekteki olaylara yardımcı olur, ancak geçmişte kaybolan kayıtları geri getirmez. Yapılandırmayı değiştirecekseniz dağıtımınızın systemd sürümünü ve log saklama politikasını kontrol edin.

Kernel, disk ve bellek belirtilerini ayırın

Loglarda BUG:, Oops:, Call Trace: veya belirli bir modül adı görmeniz çekirdek ya da sürücü katmanını işaret edebilir. I/O error, ata, nvme, EXT4-fs error, XFS veya buffer I/O ifadeleri depolama katmanını incelemenizi gerektirir. Out of memory ve OOM kayıtları ise genellikle Linux’un bellek baskısı nedeniyle süreç sonlandırdığını gösterir; bunlar her zaman kernel panic değildir.

dmesg -T --level=emerg,alert,crit,err,warn
journalctl -k -b 0 --no-pager | grep -Ei 'panic|oops|call trace|oom|io error|nvme|ata|ext4|xfs|mce|edac'

dmesg çıktısı çekirdek mesajlarını gösterir; bazı sistemlerde yetki kısıtlaması nedeniyle root erişimi gerekebilir. Komutun çıktısını daraltmak teşhisi hızlandırır, fakat grep filtresinde görünmeyen satırları yok saymayın. Hata bir donanım aygıtına işaret ediyorsa sağlayıcının disk ve sanallaştırma kayıtlarını da isteyin.

En düşük riskli kurtarma yolları

Önceki kernel ile açılışı deneyin

Son güncellemeden sonra başlayan bir sorun için GRUB menüsündeki Advanced options altında daha eski bir kernel seçmek iyi bir izolasyon testidir. Sunucu eski kernel ile açılıyorsa kök dosya sistemi, ağ ve temel servisleri doğrulayın; ardından çalışan sürümü hemen kaldırmayın.

Bu test, sorunun çekirdek paketinde veya initramfs içinde olabileceğini düşündürür, ancak donanım arızasını tamamen dışlamaz. Eski kernel ile de yük altında panic oluyorsa bellek, depolama, firmware ve sanallaştırma katmanını ayrıca inceleyin.

Rescue veya live ortamında kök diski inceleyin

Hiçbir kernel ile açılış gerçekleşmiyorsa sağlayıcının rescue ortamını veya dağıtımın live ortamını kullanın. Buradaki amaç sistemi rastgele onarmak değil, kök bölümün görüldüğünü, dosya sisteminin tutarlı olduğunu ve gerekli verilerin kopyalanabildiğini doğrulamaktır.

Önce aygıtları ve bağlama noktalarını belirleyin. Aşağıdaki örnek yalnızca keşif içindir; kendi disk adınızı çıktıdan doğrulamadan onarım komutu çalıştırmayın.

lsblk -f
blkid
findmnt
smartctl -a /dev/sdX

smartctl fiziksel donanımda yararlı bilgiler sağlayabilir, ancak sanal disklerde sınırlı veya anlamsız çıktı verebilir. /dev/sdX yer tutucusunu gerçek aygıt adıyla değiştirmeden komutu çalıştırmayın. Sağlayıcının sanal disk altyapısı için sunduğu sağlık bilgileri varsa bunları da kontrol edin. Dosya sistemi kontrolü yapmadan önce ilgili bölümü unmount edin ve mümkünse sağlayıcının anlık görüntüsünü veya doğrulanmış yedeği alın.

umount /dev/mapper/vg-root
fsck -f /dev/mapper/vg-root

Bu komutlar örnektir ve aygıt adları sisteme göre değişir. LVM, RAID, şifreli disk veya XFS kullanıyorsanız önce ilgili katmanları doğru sırada etkinleştirmeniz gerekir. Yanlış bölüme fsck uygulamak veri kaybına yol açabilir; XFS gibi dosya sistemlerinde uygun yerel araçları kullanın. Onarım tamamlandığında dosya sistemini tekrar bağlayıp temel dosyaların okunabildiğini doğrulayın.

Çekirdek paketini ve initramfs’i yeniden oluşturun

Eski kernel ile çalışan bir sistemde paket veritabanını, disk boşluğunu ve boot bölümünü kontrol edin. Boot bölümünün dolu olması, yeni kernel paketinin kurulmuş görünmesine rağmen initramfs dosyasının tamamlanamamasına yol açabilir.

df -h
findmnt /boot
ls -lh /boot

Dağıtım ve paket yöneticisi bilinmeden tek bir yeniden kurulum komutu vermek doğru değildir. Debian veya Ubuntu tabanlı bir sistemde paket bilgilerini doğrulayıp ilgili kernel paketini yeniden kurmak için APT; AlmaLinux, Rocky veya RHEL tabanlı bir sistemde DNF ve ilgili initramfs araçları kullanılır. Önce çalışan kernel sürümünü, paket adını ve dağıtım sürümünü kaydedin:

cat /etc/os-release
rpm -q kernel 2>/dev/null || dpkg-query -W 'linux-image*' 2>/dev/null

Dağıtımın resmi paketleriyle yeniden kurulum yapmadan önce yedek veya snapshot alın. Üçüncü taraf bir kernel modülü kullanıyorsanız, DKMS derleme durumunu ayrıca inceleyin; modül, yeni çekirdeğe uyumlu biçimde derlenmediyse açılış sorunu oluşturabilir. Yeniden oluşturma sonrasında initramfs dosyasının boot bölümünde bulunduğunu ve önyükleme menüsünün ilgili sürümü gördüğünü kontrol edin.

Kök nedenleri sınıflandırın

Kernel güncellemesi veya üçüncü taraf modül

Panic ilk kez kernel güncellemesinden sonra başladıysa eski kernel ile açılış testi, paket ve initramfs doğrulaması, ardından modül kayıtları izlenmelidir. NVIDIA, depolama, güvenlik veya sanallaştırma sürücüleri gibi çekirdek modülleri sürüm değişikliklerinden etkilenebilir. Hata mesajında modül adı geçmesi, modülü hemen silmeniz gerektiği anlamına gelmez; önce ilgili paketin ve DKMS durumunun kaydını alın.

Düzeltme olarak yalnızca sorunla ilişkili paketi yeniden oluşturun veya üreticinin uyumlu sürümüne dönün. Çekirdek parametrelerini topluca değiştirmeyin. Her değişiklikten sonra bir kontrollü açılış, log karşılaştırması ve uygulama servisi kontrolü yapın.

Dosya sistemi, disk veya RAID sorunu

Kök bölüm bağlanamıyorsa panic, çekirdeğin çalıştığı halde temel dosya sistemine erişemediği bir önyükleme arızası olabilir. UUID değişikliği, bozuk superblock, disk bağlantısı, RAID degradasyonu ve dosya sistemi tutarsızlığı olası nedenlerdir. /etc/fstab, initramfs içeriği ve boot parametrelerini birlikte kontrol edin.

Donanım hata kayıtları tekrarlanıyorsa yalnızca dosya sistemi onarmak kalıcı çözüm değildir. Veriyi mümkün olan en kısa sürede başka bir ortama kopyalayın, RAID durumunu ve disk sağlığını doğrulayın, fiziksel sunucuda sağlayıcı veya donanım yöneticisiyle değişim planlayın.

Bellek, CPU ve firmware

MCE, EDAC, ECC düzeltme hataları, rastgele farklı kernel izleri veya yük altında tekrarlayan kilitlenmeler donanım ihtimalini yükseltir. VPS ortamında bu belirtiler fiziksel host sorunu, sanallaştırma katmanı veya kaynak tahsisi problemiyle ilişkili olabilir. Fiziksel sunucuda üretici tanılama araçları, ECC sayaçları, sıcaklık ve firmware sürümleri incelenmelidir.

Firmware güncellemesi veri ve açılış riski taşıdığı için önce yedek, bakım penceresi ve geri dönüş planı hazırlayın. Aynı anda kernel, firmware ve sürücü değiştirmeyin; hangi değişikliğin sonucu etkilediğini ayırmak zorlaşır.

OOM ile kernel panic’i karıştırmayın

Bellek tükenince Linux OOM killer, bazı süreçleri sonlandırabilir. Bu olayda web sitesi, veritabanı veya PHP süreçleri kapanabilir; ancak çekirdek mutlaka panic yapmaz. journalctl içinde Out of memory, Killed process ve cgroup bilgilerini arayın. Swap, uygulama limitleri ve süreç bazlı bellek kullanımı incelendikten sonra kaynak artırımı veya uygulama ayarı düşünülmelidir.

PHP-FPM web işçileri ile CLI üzerinden çalışan cron veya kuyruk işçilerini de ayırın. HTTP isteği yapmayan bir CLI işi PHP-FPM web işçisi tüketmez; buna karşılık aynı sunucunun toplam belleğini tüketerek OOM olayına katkı sağlayabilir. Bu ayrım, yanlış servisi yeniden yapılandırmanızı önler.

Kdump ve pstore ile sonraki olayı yakalayın

Panic sonrasında normal disk yazımı tamamlanamayabilir. kdump, ayrılmış bir crash kernel başlatarak bellek dökümü almaya; pstore ise uygun firmware veya donanım desteği varsa bazı kernel mesajlarını yeniden başlatma sonrasında saklamaya yardımcı olur. Bunlar kurtarma mekanizması değil, gelecekteki teşhis araçlarıdır.

Kdump etkinleştirilecekse dağıtımınızın paketini, ayrılmış bellek gereksinimini ve döküm hedefinin yeterli alanını doğrulayın. Döküm dosyaları hassas bellek içeriği barındırabileceği için erişim izinlerini ve saklama politikasını da belirleyin. Önceki panic için kdump etkin değilse geriye dönük döküm üretilemez.

systemctl status kdump 2>/dev/null || true
ls -la /var/crash 2>/dev/null || true
mount | grep -E 'pstore|ramoops' || true

Bu komutlar yalnızca mevcut durumu gösterir. Kdump yapılandırmasını, dağıtım belgelerindeki çekirdek parametreleri ve dump hedefiyle birlikte uygulayın; üretim sunucusunda rastgele crashkernel değeri eklemeyin. Etkinleştirme sonrasında kontrollü bir panic testi ancak bakım penceresi, yedek ve hizmet kesintisi kabulü varsa yapılmalıdır.

Değişiklik sonrası doğrulama

Sunucu yeniden açıldığında SSH bağlantısının kurulması tek başına çözüm kanıtı değildir. Aşağıdaki sırayla doğrulama yapın:

1. Çalışan kernel ve açılış zamanını kaydedin: uname -r ve uptime -s.
2. Son açılışta yeni panic, Oops, I/O veya dosya sistemi hatası olup olmadığını inceleyin.
3. Kök ve boot bölümlerinde boş alan bulunduğunu kontrol edin.
4. Ağ arayüzünü, DNS çözümlemesini ve güvenlik duvarını test edin.
5. Veritabanı, web sunucusu, PHP-FPM, kuyruk işçileri ve zamanlanmış görevlerin durumunu ayrı ayrı kontrol edin.
6. Uygulama üzerinden basit bir okuma ve gerekiyorsa kontrollü yazma testi yapın.
7. İzleme sisteminde yeniden başlama, gecikme, disk ve bellek alarmlarının normale döndüğünü doğrulayın.

Son kernel sürümünü hemen varsayılan yapmadan önce en azından bir kontrollü yeniden başlatma planı oluşturun. Eski çalışan kernel’i, geri dönüş için yeterli süre boyunca sistemde tutun; paket temizliği yapacaksanız hangi sürümün kurtarma seçeneği olarak kalacağını önceden belirleyin.

Tekrarlayan arızalar için olay sonrası not hazırlayın: belirtiler, saat, son değişiklik, kullanılan kernel, log parçaları, yapılan düzeltme ve doğrulama sonucu. Linux sunucularda yama akışını belirlemek için yama yönetimi yaklaşımını inceleyebilir; üretim öncesi çekirdek güncellemelerini test ve geri dönüş adımlarıyla planlayabilirsiniz.

Birden fazla disk veya host katmanı etkileniyorsa tek sunucudaki düzeltme yeterli olmayabilir. Felaket kurtarma provasını düzenli uygulayarak yedeklerin gerçekten geri yüklenebildiğini, konsol erişiminin hazır olduğunu ve RTO hedefinizin uygulanabilir olduğunu doğrulayın.

Sık Sorulan Sorular

Kernel panic sunucudaki verileri siler mi?

Kernel panic tek başına verileri silmez; ancak yazma işlemi yarıda kaldıysa dosya sistemi tutarsızlığı veya son işlemlerin kaybı oluşabilir. Yeniden başlatma döngüsünü sürdürmeden önce yedek ve disk durumunu kontrol edin.

Sunucu yeniden başlıyor ama ekranda panic görünmüyorsa ne yapılmalı?

Sağlayıcı güç ve hypervisor kayıtlarını, watchdog olaylarını ve fiziksel donanım alarmlarını inceleyin. Panic ekranı otomatik yeniden başlama nedeniyle görülemeyebilir; kalıcı console log, kdump veya pstore gelecek olayda kanıt sağlayabilir.

Eski kernel ile açılan sunucuda yeni kernel silinmeli mi?

Hemen silmeyin. Önce yeni kernel paketini, initramfs’i, üçüncü taraf modülleri ve boot alanını inceleyin. Geri dönüş yolu korunurken sorunlu sürümü düzeltmek veya uygun bir güncellemeyle değiştirmek daha güvenlidir.

Kernel panic ile uygulamanın beyaz ekranı aynı sorun mudur?

Hayır. Beyaz ekran çoğunlukla uygulama, PHP, tema, eklenti veya web sunucusu katmanında oluşur; kernel panic ise işletim sisteminin çekirdek katmanında kritik durmadır. SSH ve konsol erişimiyle hangi katmanın etkilendiğini ayırın.

Uygulanabilir kontrol listesi

• Konsol erişimini açın ve panic ekranını kaydedin.
• Yeniden başlama saatini, son değişiklikleri ve sağlayıcı olaylarını eşleştirin.
• Çalışan veya eski kernel ile açılışı deneyin; çalışan sürümü silmeyin.
• journalctl, dmesg, disk, dosya sistemi, bellek ve donanım kayıtlarını birlikte inceleyin.
• Değişiklikten önce snapshot veya doğrulanmış yedek ve geri dönüş adımı hazırlayın.
• Yalnızca belirlenen katmana dar kapsamlı düzeltme uygulayın.
• Açılışı, kritik servisleri, disk durumunu ve izleme alarmlarını doğrulayın.
• Tekrarlayan olaylar için kdump, pstore ve kalıcı journal seçeneklerini planlayın.

İlk sonraki adımınız, sunucuya konsoldan erişip son panic çıktısını ve journalctl -b -1 -k sonucunu güvenli bir konuma almaktır. Bu iki kanıt, yeniden kurulum gibi geri dönüşü zor bir işlem yapmadan doğru kurtarma yolunu seçmenizi sağlar.

Emre