難攻不落(난공불락) 리눅스 및 오픈소스 인프라 세미나

발표자 : 이미르 2014. 04. 19

Linux Kernel Core Dump Analysis

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

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 파일을 생성.

Kernel Dump ?

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

Kernel Dump ?

Kernel Dump ?

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

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)

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

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

Debuginfo ?

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/

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 가 열고있는 파일디스크립터들을 출력해준다.

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 분석 요청. ** 대부분의 커널 버그는 잘 알려져 있는 버그.

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

Case 1

상황

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

Case 2

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

Case 3

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

Case 4

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

Conclusion

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

감사합니다.