일반적인 사용자 프로그램은 오류가 발생하면 GDB(GNU Debugger)를 이용해 쉽게 디버깅할 수 있습니다. 하지만 Linux Kernel은 운영체제의 핵심이기 때문에 잘못된 코드가 실행되면 시스템 전체가 멈추거나(Kernel Panic) 재부팅될 수 있습니다.
따라서 커널 디버깅은 일반 애플리케이션 디버깅과는 접근 방식이 다릅니다.
Linux는 이러한 문제를 해결하기 위해 printk, dmesg, ftrace, kgdb, kdump, crash 등 다양한 디버깅 도구를 제공합니다.
이번 글에서는 커널 개발과 운영 환경에서 가장 많이 사용하는 디버깅 도구와 각각의 역할, 활용 방법을 자세히 알아보겠습니다.
Linux Kernel 디버깅이란?
Kernel 디버깅은 커널 내부에서 발생하는 오류와 성능 문제를 분석하는 과정입니다.
전체 구조는 다음과 같습니다.
Kernel
↓
Error
↓
Debug Tool
↓
Log
↓
Analysis
↓
Fix
상황에 따라 적절한 디버깅 도구를 선택하는 것이 중요합니다.
Kernel 디버깅이 필요한 이유
대표적인 사례는 다음과 같습니다.
- Kernel Panic 발생
- Driver 오류
- 시스템 멈춤(Hang)
- 메모리 누수
- CPU 과다 사용
- 인터럽트 문제
- Deadlock 발생
이러한 문제는 일반 로그만으로 원인을 파악하기 어려운 경우가 많습니다.
printk
가장 기본적인 디버깅 방법입니다.
예시
printk(KERN_INFO "Driver initialized\n");
printk()는 Kernel 내부 로그 버퍼에 메시지를 기록합니다.
로그 레벨도 지정할 수 있습니다.
KERN_EMERG
KERN_ALERT
KERN_CRIT
KERN_ERR
KERN_WARNING
KERN_NOTICE
KERN_INFO
KERN_DEBUG
운영 환경에서는 필요한 수준의 로그만 출력하는 것이 좋습니다.
dmesg
printk()로 출력된 로그는 dmesg 명령으로 확인할 수 있습니다.
dmesg
최근 로그만 확인
dmesg | tail
실시간 확인
dmesg -w
커널 로그 분석 시 가장 먼저 사용하는 명령입니다.
ftrace
ftrace(Function Tracer)는 커널 함수 호출을 추적하는 기능입니다.
구조
Kernel Function
↓
ftrace
↓
Trace Buffer
↓
Analysis
특정 함수의 실행 흐름과 시간을 분석할 수 있습니다.
대표 기능
- Function Trace
- Function Graph
- Scheduler Trace
- IRQ Trace
ftrace 활성화
현재 Tracer 확인
cat /sys/kernel/debug/tracing/current_tracer
Function Tracer 활성화
echo function | sudo tee /sys/kernel/debug/tracing/current_tracer
Trace 결과 확인
cat /sys/kernel/debug/tracing/trace
trace-cmd
ftrace를 쉽게 사용하는 도구입니다.
기록 시작
sudo trace-cmd record -e sched_switch
결과 확인
sudo trace-cmd report
복잡한 Trace를 파일로 저장하여 분석할 수 있습니다.
kgdb
kgdb는 Kernel용 GDB입니다.
구조
GDB
↓
kgdb
↓
Linux Kernel
원격으로 커널 내부를 디버깅할 수 있습니다.
대표 기능
- Breakpoint
- Step 실행
- 변수 확인
- 메모리 확인
커널 개발 과정에서 많이 사용됩니다.
kdump
Kernel Panic이 발생했을 때 메모리를 저장하는 기능입니다.
구조
Kernel Panic
↓
kdump
↓
vmcore
↓
Analysis
장애 분석에서 매우 중요한 역할을 합니다.
crash
vmcore를 분석하는 대표 도구입니다.
실행
crash vmlinux vmcore
분석 가능한 내용
- Process
- Memory
- Stack
- CPU 상태
- Kernel 구조체
대규모 서버 환경에서 많이 사용됩니다.
perf
성능 분석에도 자주 사용됩니다.
예시
sudo perf top
CPU 사용량 분석
sudo perf record
결과 확인
sudo perf report
커널 성능 병목 분석에 효과적입니다.
Lockdep
Deadlock을 분석하는 기능입니다.
구조
Lock
↓
Dependency Check
↓
Deadlock Detection
잠금 순서 문제를 발견하는 데 유용합니다.
Dynamic Debug
Kernel 코드를 수정하지 않고 Debug 로그를 활성화할 수 있습니다.
예시
echo 'file drivers/net/* +p' \
> /sys/kernel/debug/dynamic_debug/control
필요한 부분만 로그를 출력할 수 있어 운영 환경에서도 활용됩니다.
주요 디버깅 도구 비교
| 도구 | 용도 |
|---|---|
| printk | 로그 출력 |
| dmesg | Kernel 로그 확인 |
| ftrace | 함수 추적 |
| trace-cmd | Trace 기록 |
| kgdb | 원격 디버깅 |
| perf | 성능 분석 |
| kdump | 메모리 덤프 생성 |
| crash | vmcore 분석 |
| Lockdep | Deadlock 분석 |
상황에 따라 여러 도구를 함께 사용하는 경우가 많습니다.
실무에서 자주 사용하는 명령어
Kernel 로그 확인
dmesg
실시간 로그
dmesg -w
Tracer 확인
cat /sys/kernel/debug/tracing/current_tracer
Function Tracer 활성화
echo function | sudo tee /sys/kernel/debug/tracing/current_tracer
Trace 결과 확인
cat /sys/kernel/debug/tracing/trace
CPU 성능 분석
sudo perf top
Crash 분석
crash vmlinux vmcore
실무 사례
예를 들어 새로운 네트워크 드라이버를 개발한 뒤 서버가 간헐적으로 멈춘다고 가정해 보겠습니다.
실무에서는 다음과 같은 순서로 문제를 분석합니다.
printk()를 추가하여 주요 함수 실행 여부 확인dmesg로 오류 메시지 분석ftrace로 함수 호출 순서 확인perf로 CPU 사용량 분석- Kernel Panic 발생 시
kdump로vmcore생성 crash도구로 Stack Trace와 메모리 상태 분석- 원인을 수정한 뒤 동일한 환경에서 재검증
이처럼 커널 디버깅은 하나의 도구만 사용하는 것이 아니라 여러 도구를 조합하여 문제를 단계적으로 분석하는 방식으로 진행됩니다.
자주 묻는 질문
printk와 printf의 차이는 무엇인가요?
printf()는 사용자 공간(User Space) 프로그램에서 사용하는 함수입니다. 반면 printk()는 Kernel Space에서 사용하는 로그 출력 함수로, 커널 로그 버퍼에 메시지를 기록합니다.
ftrace와 perf는 어떤 차이가 있나요?
ftrace는 함수 호출과 실행 흐름을 추적하는 데 중점을 둡니다. perf는 CPU 사용량, 캐시 미스, 성능 병목 등 시스템 성능 분석에 특화되어 있습니다.
Kernel Panic이 발생하면 가장 먼저 무엇을 확인해야 하나요?
먼저 dmesg 로그를 확인하고, kdump가 설정되어 있다면 생성된 vmcore를 crash 도구로 분석하는 것이 일반적인 절차입니다.
마무리
Linux Kernel 디버깅은 단순히 오류 메시지를 확인하는 것을 넘어 시스템 내부의 동작을 깊이 분석하는 과정입니다. printk와 dmesg는 기본적인 로그 분석을, ftrace와 perf는 실행 흐름과 성능 분석을, kgdb, kdump, crash는 심층적인 문제 해결을 지원합니다. 각 도구의 특징을 이해하고 적절히 활용하면 커널 개발과 장애 분석을 훨씬 효율적으로 수행할 수 있습니다.