Linux Call Trace 로그를 읽고 분석하는 방법

작성자:

Linux 서버에서 Kernel Panic, Kernel Oops, 드라이버 오류 등이 발생하면 로그에 Call Trace가 함께 출력되는 경우가 많습니다. 많은 관리자는 이 로그를 복잡한 디버깅 정보라고 생각하고 지나치지만, 실제로는 문제의 원인을 찾는 데 가장 중요한 단서입니다.

Call Trace는 커널이 오류를 발생시키기 직전 어떤 함수들을 순서대로 호출했는지를 보여주는 기록입니다. 이를 분석하면 어느 커널 모듈에서 문제가 시작되었는지, 어떤 함수에서 예외가 발생했는지를 확인할 수 있습니다.

이번 글에서는 Linux Call Trace 로그를 읽는 방법과 실무에서 활용하는 분석 절차를 알아보겠습니다.

Call Trace란 무엇인가?

Call Trace는 프로그램이나 커널이 현재 위치에 도달하기까지 호출한 함수들의 목록입니다.

Kernel Panic이나 Kernel Oops가 발생하면 다음과 같은 형태의 로그가 출력됩니다.

Call Trace:
 dump_stack
 panic
 do_page_fault
 ext4_write_begin
 vfs_write
 ksys_write

위 예시는 ksys_write()에서 시작된 파일 쓰기 작업이 ext4_write_begin()을 거쳐 do_page_fault()에서 문제가 발생했고, 최종적으로 panic() 함수가 호출되었음을 의미합니다.

Call Trace가 출력되는 대표적인 상황

다음과 같은 경우 Call Trace가 함께 출력됩니다.

  • Kernel Panic
  • Kernel Oops
  • NULL Pointer Dereference
  • Segmentation Fault
  • General Protection Fault
  • Soft Lockup
  • Hard Lockup
  • Driver Crash
  • Kernel BUG
  • WARN_ON()

실무에서는 Call Trace 전체를 복사하여 분석하는 것이 매우 중요합니다.

1. Call Trace 로그 확인하기

현재 커널 로그에서 Call Trace를 검색합니다.

dmesg | grep -A 30 "Call Trace"

또는

journalctl -k | grep -A 30 "Call Trace"

-A 30 옵션은 Call Trace 이후 30줄까지 함께 출력하여 전체 호출 흐름을 확인할 수 있게 해줍니다.

2. Kernel Oops 로그 확인하기

Kernel Oops와 함께 출력되는 경우가 많습니다.

dmesg | grep -Ei "Oops|BUG|Call Trace"

또는

journalctl -k | grep -Ei "Oops|BUG"

Oops 메시지와 Call Trace를 함께 분석하면 원인을 파악하기 쉽습니다.

3. 함수 호출 순서 읽기

다음과 같은 Call Trace가 있다고 가정해 보겠습니다.

Call Trace:
 ext4_write_begin
 generic_file_write_iter
 vfs_write
 ksys_write
 __x64_sys_write

가장 아래 함수에서 시스템 호출이 시작되고, 위쪽으로 올라가면서 커널 내부 함수들이 호출됩니다.

가장 위쪽 함수 근처에서 실제 오류가 발생한 경우가 많습니다.

4. 문제가 발생한 모듈 확인하기

Call Trace 위쪽에는 다음과 같은 정보가 함께 출력되는 경우가 있습니다.

Modules linked in:

현재 로드된 모듈은 다음 명령으로 확인합니다.

lsmod

특정 모듈 정보는 다음과 같이 확인할 수 있습니다.

modinfo 모듈명

서드파티 모듈이나 최근 설치한 드라이버가 원인인 경우가 많습니다.

5. 커널 버전 확인하기

Call Trace 분석 시 커널 버전도 매우 중요합니다.

uname -r

동일한 Call Trace라도 커널 버전에 따라 원인이 달라질 수 있습니다.

6. 심볼(Symbol) 정보 확인하기

디버그 심볼이 설치되어 있다면 함수 정보를 더 자세히 확인할 수 있습니다.

예를 들어 addr2line 명령을 사용할 수 있습니다.

addr2line -e vmlinux 주소

또는

nm vmlinux

개발 환경에서는 디버그 심볼을 함께 설치하는 것이 분석에 도움이 됩니다.

7. Crash Dump 분석하기

kdump가 활성화되어 있다면 Crash Dump를 분석합니다.

Crash Dump 위치

ls /var/crash

분석

crash vmcore

Call Trace를 보다 상세하게 확인할 수 있습니다.

8. 이전 부팅 로그 확인하기

재부팅 후에는 이전 부팅 로그도 확인합니다.

journalctl -k -b -1

동일한 Call Trace가 반복되는지 확인합니다.

9. 하드웨어 오류 확인하기

메모리나 CPU 오류로도 Call Trace가 출력될 수 있습니다.

하드웨어 이벤트 확인

ipmitool sel list

ECC 메모리 오류나 CPU Machine Check Exception(MCE)이 기록되어 있는지 확인합니다.

10. 커널 소스와 비교하기

개발 환경에서는 Call Trace에 나온 함수를 커널 소스 코드에서 찾아보는 것도 좋은 방법입니다.

예를 들어

ext4_write_begin

함수가 반복적으로 나타난다면 EXT4 파일 시스템 관련 문제를 의심할 수 있습니다.

함수 이름만으로도 어느 영역에서 문제가 발생했는지 판단할 수 있습니다.

Call Trace를 분석하는 순서

실무에서는 다음 순서대로 분석하는 것이 효율적입니다.

  1. dmesg 확인
  2. journalctl -k 확인
  3. Call Trace 전체 확인
  4. 함수 호출 순서 분석
  5. 커널 모듈 확인
  6. 커널 버전 확인
  7. Crash Dump 분석
  8. 이전 부팅 로그 확인
  9. 하드웨어 로그 확인
  10. 커널 소스와 비교

이 순서대로 진행하면 대부분의 Kernel 오류 원인을 분석할 수 있습니다.

Call Trace 분석 시 주의할 점

Call Trace에 나타나는 가장 위의 함수가 항상 원인이라는 의미는 아닙니다.

실제 원인은 그 이전 함수나 드라이버에서 발생했을 수도 있으므로 Call Trace 전체 흐름과 함께 BUG, Oops, Kernel Panic 메시지를 종합적으로 확인해야 합니다.

또한 동일한 함수 이름이 반복된다고 해서 항상 같은 문제인 것은 아니므로 커널 버전과 모듈 정보도 함께 확인하는 것이 중요합니다.

자주 묻는 질문

Call Trace만 보면 원인을 알 수 있나요?

아닙니다. BUG, Oops, 커널 버전, 모듈 정보, Crash Dump 등을 함께 분석해야 정확한 원인을 파악할 수 있습니다.

Call Trace가 너무 길게 출력됩니다.

오류 발생 지점 전후의 함수와 모듈을 중심으로 확인하고, 필요하면 전체 로그를 저장하여 분석하는 것이 좋습니다.

모든 Kernel Panic에 Call Trace가 출력되나요?

대부분 출력되지만, 매우 심각한 하드웨어 장애나 갑작스러운 전원 차단의 경우 충분한 로그가 남지 않을 수도 있습니다.

마무리

Call Trace는 Linux 커널 장애 분석에서 가장 중요한 정보 중 하나입니다. dmesg, journalctl, lsmod, crash, ipmitool 등을 함께 활용하면 단순히 오류를 확인하는 수준을 넘어 실제 원인까지 추적할 수 있습니다. 특히 Kernel Panic이나 Kernel Oops가 발생했다면 Call Trace 전체를 확보하고 함수 호출 흐름을 분석하는 습관이 안정적인 서버 운영에 큰 도움이 됩니다.

댓글 남기기