1. 難攻不落(난공불락) 리눅스 및 오픈소스 인프라 세미나
발표자 : 이미르
2014. 04. 19
Linux Kernel Core Dump Analysis

2. Table of Content
 Kernel Dump ?
 분석을 위한사전준비사항 – kdump 설정, debuginfo
 Introduce to Crash tool
 Case 별 분석
- Memory 문제 (1개)
- Cpu stuck 문제 (1개)
 - Other modules (3rd-party) 문제 (1개)
- CRASH tool 의 다양한 접근 방법
 Conclusion

3. Kernel Dump ?
일반 소프트웨어에서 Segment Violation 또는 메모리 할당 오류등이 발생시,
Segment Fault 가 나며, 프로그램이 종료되는 것과 마찬가지로,
Kernel 역시 실행중 여러가지 이유로 인해,
Kernel program 이 죽을 수 있음 - Panic
Kernel 은 OS 의 핵심 Space 를 차지하기 때문에, 이와같은 Panic 상황에서
원인을 밝혀 낼 core file 이 필요.
Linux Kernel Core Dump – linux 에서는 vmcore file 이라고도 부르며,
커널의 Crash 가 발생할 경우, 발생 시점의 디렉토리아래,
Vmcore 라는 파일명의 Memory dump 파일을 생성.

4. Kernel Dump ?
Kdump / Kexec
Kernel 에서 발생한 특정 이슈에 대해서 발생시의 상황과 Memory
상태를
파일로 복사하여 문제 상황을 추적/분석 하여 추후 재발을 방지하기
위한
메카니즘.
Linux 에서는 kdump 라는 프로세스에서 kexec 라는 프로그램을 이용,
이미 예약해 둔 메모리 영역을 이용하여 임시 커널을 로드,
커널패닉이 발생했을 때, 문제된 커널의 메모리 상태를 vmcore 라는
파일 형태로 생성하는 솔루션이 제공.

5. Kernel Dump ?

6. Kernel Dump ?
출처 : Open Source Consulting Tech Blog
http://www.openseed.co.kr/blog/?p=19

7. Kernel Dump ?
How to configure to Kernel Dump
1. Kexec-tools 패키지 필요.
2. grub.conf 에 crash kernel 을 위한 parameter 설정 필요. (리부팅 필요)
3. kernel dump file 을 저장하기 위한 충분한 저장공간.
* crashkernel = kernel crash 때, kdump 및 kexec 에서 상태캡쳐를 위해
사용될 공간을 설정하는 boot parameter
title Oracle Linux Server (2.6.32-400.34.3.el5uek)
root (hd0,0)
kernel /vmlinuz-2.6.32-400.34.3.el5uek ro root=/dev/mapper/VolGroup00-LogVol00 crashkernel=400M@64M
numa=off clocksource=hpet elevator=noop console=tty0 console=ttyS0,115200
initrd /initrd-2.6.32-400.34.3.el5uek.img
title Oracle Linux Server (2.6.18-371.6.1.0.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-371.6.1.0.1.el5 ro root=/dev/mapper/VolGroup00-LogVol00 crashkernel=400M@64M
numa=off clocksource=hpet elevator=noop console=tty0 console=ttyS0,115200
initrd /initrd-2.6.18-371.6.1.0.1.el5.img
title Oracle Linux Server (2.6.18-371.4.1.0.1.el5)

8. Pre-requisite
1. 해당 커널 버젼에 맞는 Debuginfo 패키지 필요.
( debug info package 다운로드 스샷등 추가 )
2. Crash 라는 커널덤프 분석용 툴 필요.
3. 참조할 커널 코드
- 일반적으로 kernel-{version}.src 등의 패키지에서 확인 가능함.
- Web page (git)등을 통해 간단히 Diff 또는 소스코드를 직접 확인 가능.
사진 : http://lxr.free-electrons.com
Kernel Dump Analysis

9. 컴파일 시, Kernel 에 대한 debug 정보를 함께 포함하여 컴파일 한
디버깅용 패키지.
해당 패키지에서 제공되는 vmlinux 라는 파일이 커널 분석에 함께 필요함.
* redhat :
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/x86_6
4/Debuginfo/
* centos :
http://debuginfo.centos.org/
* oracle :
https://oss.oracle.com/el5/debuginfo/
https://oss.oracle.com/el6/debuginfo/
Debuginfo ?

10. CRASH ?
* GDB 로는 커널코어, mcore, Xen 또는 S390 덤프파일들을 읽기 어려웠음.
* dumpfiles 의 포맷이 각각 조금씩 달라 분석에 어려움이 있었음.
* 거의 모든 종류의 LKCD ( Linux Kernel Core Dump ) 파일을 지원하기 위해
개발.
* Disasembly, Kernel Stack Trace, Memory trace, kernel structure & variable
등을
GDB 명령형식으로 확인 할 수 있게끔 개발됨.
Kdump 에 대한 Redhat White-paper ( web ) :
http://people.redhat.com/anderson/crash_whitepaper/

11. CRASH ?
* 주요 명령어
sys - 시스템의 일반적인 정보를 출력해 준다.
bt - Backtrace 명령. 스택의 내용들을 순차적으로 출력해준다.
ps - Process list 출력.
free - Memory 및 스왑 상태 출력.
mount - 마운트 상태 출력
irq - 각 장치의 ( irq ) 상태를 출력.
kmem - 메모리 상태 출력 ( kmalloc, valloc 등 메모리 할당 상태도 보여줌 )
log - dmesg 의 내용을 출력.
mod - 로딩된 모듈 리스트 출력.
net - Network 상태 출력.
runq - 실행중인 task 리스트 출력.
task - 작업목록 출력.
rd - 메모리 번지수에 대한 상세정보 출력.
foreach - 모든 task, process 등 디버깅 정보에 대한 상세한 출력이 가능함.
set - 설정된 주소 및 PID 등을 기본 컨텍스트로 설정.
struct - 구조화된 메모리 내부의 변수들을 출력해 준다.
files - task 가 열고있는 파일디스크립터들을 출력해준다.

12. Simple Sequence for LKCD Analysis
1. debug info 로 부터 vmlinux 추출
2. CRASH tools 을 이용한 corefile 과 vmlinux 로드.
3. 커널 로그 확인.
4. 메모리 상태 확인.
5. backtrace 를 통한 최종 stack 내용 확인
6. 최종 스택의 Return Address 의 내용을 Code 또는 Dis-Assembly 를 통해 확인.
7. 버그 정보 검색.
8. 버그일 경우 해당 패치정보 검색.
9. 알려지지 않은 버그일 경우 해당 벤더에 버그 오픈 또는 Advanced 분석 요청.
** 대부분의 커널 버그는 잘 알려져 있는 버그.

13. Case 별로 알아가는 LKCD Analysis
 버그 및 Stack trace 내용에 대한 Database 를 보유하는 것이 중요하다.
 이슈에 대한 분류
- Memory
- Cpu 문제
- H/W 이슈
- Other modules (3rd-party)
 상위 커널 업그레이드로 해결되는 경우가 대부분이다.
Debuginfo 에서 vmlinux 추출 방법
-rpm2cpio kernel-debuginfo-{version}.x86_64.rpm | cpio -ivd

14. Case 1
 상황
-Console 및 네트웍으로 전혀 접속할 수 없어 서비스도 되지 않았으나,
ping 은 가고 있던 이른바 hang up 상태의 시스템에서 시그널을 발생시켜
얻어낸 vmcore.
- 시스템 Hangup 의 원인이 밝혀져야 하는 상황.
 분석과정
-file:///Case_1_memoryissue.odt

15. Case 2
 상황
- 알수 없는 이유로 시스템이 백업도중 Crash.
백업을 위한 용도로 주로 사용되는 미디어 서버.
 분석과정
-file:///Case_2_kernelbug.odt

16. Case 3
 상황
- 시스템 Crashed. Vmcore 생성을 통한 분석요청.
 분석과정
-file:///Case_3NMI_signal_partial.odt

17. Case 4
 상황
- 시스템 Crashed. Vmcore 생성을 통한 분석요청.
 실제 vmcore 파일을 이용한 분석 과정 재현.

18. Conclusion
 커널 덤프분석으로 완벽한 원인 분석을 하는 것은 매우 어렵다.
 많은 분석에 대한 Case 를 Data 로 보유하는 것이 dump 분석에 대한
노하우이다.
 Stack trace 만으로 추측 할 수 있는 부분은 거의 없다.
 많은 시간의 분석 시간이 소요 될 수 있으며, dump 만으로 분석하는 것 보다는,
다양한 system log 및 자료들을 이용하여 (sosreport) 병행해서 접근해야 한다.
 대부분의 커널 버그는 Kernel update 로 해결된다.
- 실재 새로운 버그를 찾기는 어려우며,
- kdump 분석을 통해, 더 낫고 빠른 문제해결 또는 재발방지를 위한 방편임을
잊지 말자.
 3rd-party 모듈 사용시에는 해당 vendor 의 지원이 필요하다.
( Stack 내용을 정확히 볼 수 없기 때문 )

19. 감사합니다.