Zaman zaman core dosyası ile crash dosyası karıştırılmaktadır. Bu iki dosya tipi nedir, ne zaman oluşur, nasıl analiz edilir onu inceleyelim.

Uygulama Sebepli Core Dosyası

Core dosyası  programın beklenmedik şekilde sonlanması ya da sonlandırılması(abnormal termination) sonucu oluşan dosyalardır.  Bu sonlanma programsal bir hata da olabilir ya da dışarıdan gelen bir sinyal ile de gerçekleşebilir.  Genelde filesystemi  doldurdugunu gorerek fark ettiğimiz core dosyalarını yer sorunundan kurtulmak amacıyla direkt silmeden önce nedenini araştırmamız olası uygulama sorunlarına çözüm bulmamız amacıyla önem arzediyor.

Bizim isteğimiz dışında eğer bir core dosyası oluşuyorsa, bu core dosyasının neden ve hangi uygulama nedeniyle oluştuğunu görmek için file komutunu kullanabiliriz. Eğer konfigurasyon dosyalarında aksi belirtilmemişse, core dosyası uygulamanın çalıştırıldığı aynı dizin altında oluşur.

# file core
  core: core file from 'FastReader' - received SIGABRT

Bu örnekte fastreader programının SIGABRT sinyali alması nedeniyle core dosyası oluşturduğunu görebiliriz. Sinyal tipleri ve hangi anlamlara geldiği programsal olduğu için o konuya burada girmeyeceğiz. Daha detaylı bilgi almak için What komutu da kullanılabilir. Core dosyası binary bir dosya olduğundan strings komutu ile de core içindeki text veriler görüntülenebilir.

                Daha detaylı bir analiz gdb ya da wdb toolu ile yapılmaktadır. Wdb  , sunucu üzerinde default olarak gelen gdb(gnu debugger)  tolunun, hp tarafından görsel arayüz eklenmiş şeklidir. Aşağıdaki adresten indirilebiliyor.

http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=cb080f1bace021100f1bace02110275d6e10RCRD

Gerek gdb gerek wdb ile debug yapabilmemiz için uygulamanın debug edilebilir şeklinde derlenmesi gerekiyor. Ancak bu şekilde anlaşılabilir metin verilerine ulaşabiliriz. Yoksa içinden çıkılması zor hex değerlerle ulaşmak sizi bilmem ama benim pek harcım değil :) gdb ile de debug şu şekilde yapılıyor.

# gdb –c core /usr/bin/fastreader

Daha sonra çıkan ekranda bt komutu ile hangi fonksiyon çalışırken, hangi değer ne iken programın çalışması durduğunu bulabilirsiniz.

Sistem Crash Dosyaları

Sistem crash sunucumuzda büyük bir problem oldugunda meydana gelir ve uygulama core dosyası kadar masum olmayan loglar içerirler  :)  Sunucunuz  üzerinde HPMC denen(High priority machine check)  bir durum oluştuğunda  meydana gelir. Ve büyük ihtimal nedeni bir donanım problemidir.  Bu problem işletim sisteminin handle edemediği bir cpu problemi, PCI I/O kart problemi v.s. olabilir.

Sistem crash dosyasının nasıl analiz edileceğine geçmeden önce bu dosyanın nasıl oluştuğuna dair sürece göz atmakta fayda var. Alttaki şemayı kaynaklarda belirttiğim dökümandan aldım.

Şemayı açıklamak istersek;

• Problem sırasında kernel problemi çözemediğine dair log düşer (Kernel Panic )

• Fiziksel belleğin bir kısmı ya da hepsi dump devices adı verilen alana yazılmaya başlar. Bu yazılma işlemi sunucu konsol ekranından takip edilebilir. Dump’ın hangi alana yazılacağı  aşağıdaki komutla görülebilir.

# /sbin/crashconf –v

• Sistem crash süreci( nereye yazılacağı, alınıp alınmayacağı, hangi verilerin dump edileceği.. ) gibi ayarlar /etc/rc.config.d/crashconf dosyasında belirtilebilir ya da sunucu çalışırken crashconf uygulamasıyla değiştirilebilir.

• Crash datası dump device larına yazıldıktan sonra sunucu tekrar başlatılır ve tekrar dump datası yazma işlemine başlar. Bu sefer yazma dump device larından disk üzerinde tanımlanan filesystem üzerindeki bir alandır. Bu alan genelde /var/adm/crash üzerine yazılacak şekilde ayarlanır.

Sistem hang oldugunda yani cevap veremez duruma geldiğinde sorunun nedenini anlamak amacıyla aynı süreci çalıştırmak için MP üzerinden sunucuya TOC( Transfer of Control) sinyali gönderilebilir.

Bazı konuları tekrar söylemekte fayda var. Sistem crash analizi aslında HP destek mühendislerinin ayrıntılı olarak yapması gereken bir iş. Sonuçta arızalı bir parça varsa onların değiştirmesi gerekiyor(NŞA da) . İkinci olarak  bakacağımız dosyalar veya o dosyalardaki loglar,  sunucu tekrar restart olduktan sonra oluşuyor. Bu loglar  da dump edilen verilerden geliyor.

Crash sürecini gördük. Şimdi ise bir sunucu crash oldugunda nereye, nasıl bakacağımızı görelim.

1. İlk olarak /etc/shutdownlog dosyasına bakalım. Bu dosya hangi kullanıcının sunucuyu reboot ettiğini ya da neden reboot olduguna dair bir ipucu verebilir.

2.  Crash datası oluşturulurken, datanın bir örneği /var/tombstones altındaki dizine de kopyalanır. Bu dizindeki ts99 dosyası vi ile açılarak son loglara bakılabilir. Genelde bu dosya yine HP tarafından analiz edilmesi gerekiyor. Ama metin olarak da bize anlamlı bilgiler verebilir.

3. Asıl crash analizi ise /var/adm/crash altındaki dosyalar ile yapılıyor. Bu dizin altında crash.0, crash.1, .. gibi alt dizinler bulunabilir. İndeksi en büyük olan crash dizini en son oluşturulandır. Ayrıca dizinin değiştirilme tarihinden de bulabilirsiniz. Şimdi en son oluşan crash dizininin altına geçelim ve analiz işlemlerine başlayalım.

1. crash dizinin altındaki vmunix.gz dosyasını açalım.

# gunzip vmuniz.gz

2.  Dump tolunu hazır hale getireli

# q4prep –p

 3. q4 komut satırına düşelim.

# q4 –p .

4. Şimdi yazacağımız komut sorun oluştuğunda ne oldugunu gösteriyor.

     # trace event 0

Çıktıyı dosyaya yönlendirnmek için

     # trace event 0 > trace_event_0.out

5.     #include analyze.pl;
     #run Analyze AU >> analiz.out

6.        #run WhatHappened -HANG > what.out  

7.        # exit

crash dizini altında şimdi analiz.out, what.out ve trace_event_0.out adında dosyaların oluşması lazım. Bu dosyalar sorun hakkında bilgiler içeren dosyalardır.

Son olarak, bütün bu işlemleri bizim yerimize yapan crashinfo adında bir tool var. Fakat HP nin kendi geliştirdiği bir tool oldugu için sadece HP çalışanları tarafından bir sorun oldugu zaman veriliyor. Elinizde crashinfo toolu varsa analiz için gerekli dosyaları da aşağıdaki şekilde oluşturabilrsiniz.

1. crashinfo uygulamasını crash dizini altına kopyalayalım ve bu dizininin altına geçelim.

2.          # chmod 744 crashinfo.exe

3. Alttaki işlem ile analizi yapacak crashinfo dosyasını oluşturalım.  

# ./crashinfo.exe

4.         # ./crashinfo -t > /tmp/crashinfo_t.txt
            # ./crashinfo -v > /tmp/crashinfo_v.txt
            # ./crashinfo -c > /tmp/crashinfo_c.txt

Oluşan dosyalar metin dosyalardır. Sunucunun crash oldugu andaki  bütün bilgilerini bu dosyalarda görebiliriz.

Kaynaklar:

1. http://docs.hp.com/en/B2355-90950/ch05s05.html

2. http://docs.hp.com/en/sysdmp-62001/ch01.html

3. http://en.wikipedia.org/wiki/Kernel_panic

4.http://www13.itrc.hp.com/service/cki/docDisplay.do?docId=emr_na-c01021636-6&docLocale=en&admit=109447627+1278075592355+28353475

5. http://itrc.hp.com