Linux) Kdump 활용해서 원인 분석하기(2)

이 글을 보기 전 읽으면 도움될 개념

 

 

Linux) Kdump 활용해서 원인 분석하기(1)

 

 

Core Dump 생성  - LAB

 

정상적인 서버를 억지로 Kernel Panic(커널 패닉) 상태로 빠지게 만들기 위해 아래와 같은 명령어를 입력합니다.

명령이 입력되면 메모리 상태의 덤프를 뜬 vmcore라는 파일이 생성됩니다. 별도의 설정을 하지 않았으면 Core Dump 파일은 "/var/crash"에 저장이 됩니다.

 

# echo c > /proc/sysrq-trigger

테스트를 위한 명령이므로  절대로 운영중인 장비에 입력하지 않기를 바랍니다.

 

 

갑자기 사용중인 세션이 끊기면서 서버가 재기동되었습니다. 커널 패닉 현상이 발생했기 때문에 "/var/crash" 쪽에 vmcore 파일이 떨어집니다. 

 

 

Core Dump가 정상적으로 떨어졌는지 확인합니다.  1차적으로 vmcore-dmesg를 통해 분석을 한 후 정확한 원인이 파악이 되지 않으면 vmcore 파일을 가지고 분석을 시작합니다.

 

dmesg: 부팅 메세지가 담긴 로그

 

 

Core Dump 분석  - LAB

 

갑작스럽게 커널 패닉이 일어나서 재기동이 됐을 당시 시스템의 부팅 메세지가 관련된 vmcore-dmesg 파일을 확인합니다.

 

# vi /var/crash/127.0.0.1-2021-04-29-20:32:26/vmcore-dmesg.txt

 

모든 로그를 담기는 애매하고 특정 로그를 담아서 최대한 표현하는 방식으로 진행하려고 합니다.

 

[ 0.000000] Linux version 3.10.0-1160.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-1160.el7.x86_64 root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=en_US.UTF-8

☞ 3.10.0-1160-el7 커널과 "/vmlinuz-3.10.0-1160.el7.x86_64" 부팅 이미지 등 부트로더(GRUB)와 관련된 메세지가 나오는 것으로 보아 서버가 재기동 됐음을 예측합니다.

 

이후에는 POST 과정을 거칩니다. 이 중 하드웨어 단에서 에러 로그가 보인다면 기록해놨다가 알려줘야 됩니다.

Info성 로그로 서버 운영에 문제가 없는 로그들이 많습니다. 이들은 나오는 녀석들만 나오는 경우도 많으니 최대한 많은 로그를 눈에 익히는 것이 좋습니다.

 

 

[ 790.371036] SysRq : Trigger a crash

☞ 누군가가 SysRq를 이용해 Trigger시켜서 커널 패닉상태로 만들었음을 예측합니다.


[ 790.371131] Oops: 0002 [#1] SMP

☞ 결국에 Oops 로그를 발생하면서 현재 커널 상태가 비정상이고 패닉 상태임을 알려줍니다.


[ 790.371441] RIP: 0010:[<ffffffffb3c74856>] [<ffffffffb3c74856>] sysrq_handle_crash+0x16/0x20

☞ sysrq를 이용한 크래쉬로 인해 패닉 상태에 빠진 것으로 예상됩니다.


[ 790.371594] Call Trace:
                   [ 790.371603] [<ffffffffb3c7507d>] __handle_sysrq+0x10d/0x170
                   [ 790.371616] [<ffffffffb3c754e8>] write_sysrq_trigger+0x28/0x40


☞ 죽은 위치를 확인하기 위한 정보에 표시된 그 함수가 호출되기까지 호출되는 함수에 대한 정보를 뜻하는 Call Trace 부분을 지켜본 결과 sysrq trigger 관련 작업을 특정 시간에 했을 것으로 예측합니다.

 

만약 위와같이 dmesg로만 분석이 가능하다면 vmcore 파일을 완전 자세하게 깔 필요는 없어 보입니다. 

일단 지금은 초반부이기 때문에 추가적인 분석은 자제하고 나중에 crash를 통해 역추적을 해서 원인을 찾아내는 글을 작성하려고 합니다.