1. Intro
특정 지점이나 거점을 무인으로 운영하기 위해 필요한 서버를 둘 경우가 있습니다. 이때 불필요한 지출을 줄이기 위해 Raspberry Pi, 하드커널의 Odroid와 같은 소형 서버를 두고 운영하는 것도 좋은 방법입니다. 하지만 무인 운영 과정에서 서버에 이슈가 있거나 임베디드 장비에서 에러가 발생하여 커널 패닉과 같은 심각한 이슈가 발생할 경우 서비스 중단을 초래할 수 있습니다. 이 경우 수동으로 사람이 개입하지 않고 자동으로 복구(재부팅) 되도록 하여 서비스 가용성을 높일 필요가 있습니다.
이번 포스트에서는 Odroid에서 커널 패닉이 발생하거나, 이에 준한 이슈가 발생할 경우 서비스를 재부팅하기 위한 방법을 리서치한 내용을 작성하였습니다.
2. Kernel Panic?
리눅스 커널 패닉은 운영 체제가 복구할 수 없는 치명적인 오류를 발견했을 때 발생하는 상황입니다. 이는 마치 윈도우의 "블루 스크린 오브 데스(BSOD)"와 유사합니다. 커널은 더 이상 안정적으로 작동할 수 없다고 판단하고 모든 작업을 중단합니다. 이 상태에서는 시스템이 완전히 멈추고 어떠한 사용자 입력에도 응답하지 않게 됩니다. 하지만 이러한 상태를 방지하기 위해 Linux 시스템에는 여러 대응방안이 있습니다. 그 중 Watchdog는 리눅스 시스템에서 안정성과 가용성을 보장하기 위한 매우 중요한 서비스입니다.
Watchdog
시스템이 예상치 못한 오류로 인해 멈추거나 응답하지 않는 상황(System Hang, Kernel Panic 등)에서 자동으로 시스템을 복구(주로 재부팅)하도록 설계되었습니다. 간단히 말해 watchdog는 시스템이 살아있는지 지속적으로 확인하고 만약 시스템이 더 이상 응답하지 않는다고 판단되면 미리 정해진 조치를 취하는 “감시자” 역할을 합니다.
watchdog는 크게 두 가지 구성 요소로 작동합니다. 하드웨어 워치독 타이머와 워치독 데몬(소프트웨어)의 두 가지에 대해 알아보겠습니다.
하드웨어 워치독 타이머 (Hardware Watchdog Timer)
대부분의 서버, 임베디드 시스템, 그리고 일부 데스크톱/랩톱에는 메인 CPU와 독립적으로 작동하는 특수 하드웨어 칩(타이머)이 내장되어 있습니다. 이 하드웨어 타이머는 특정 시간(예: 60초) 동안 "리셋" 신호를 받지 못하면, 시스템에 강제로 전원을 껐다 켜는 것과 같은 하드웨어 리셋을 발동시키게 됩니다.
하드웨어 타이머는 운영 체제가 완전히 멈추거나 CPU가 마비되어도 작동하기 때문에, 소프트웨어적인 문제로 인한 시스템 행에 대한 궁극적인 안전장치 역할을 합니다. 리눅스 커널은 /dev/watchdog라는 특수 장치 파일을 통해 이 하드웨어 워치독 타이머와 통신합니다.
워치독 데몬 (watchdogd)
watchdogd는 리눅스 시스템에서 실행되는 소프트웨어 서비스입니다. 이 데몬은 시스템이 정상적으로 작동하고 있음을 나타내는 "하트비트(heartbeat)" 신호를 주기적으로 /dev/watchdog 장치에 보냅니다. 이 행위를 "워치독 피딩(feeding the watchdog)"이라고 합니다. 만약 시스템이 행(hang)되어 watchdogd가 더 이상 /dev/watchdog에 하트비트를 보내지 못하게 되면, 하드웨어 워치독 타이머가 만료되고 시스템은 강제로 재부팅됩니다.
watchdogd는 /etc/watchdog.conf 파일을 통해 다양한 시스템 상태를 모니터링하도록 설정할 수 있습니다.
•
평균 시스템 로드(load average) : 시스템 부하가 너무 높아지면 응답 불능으로 간주하고 재부팅.
•
특정 파일의 존재 여부 : 중요한 파일 시스템이 마운트 해제되었는지 확인.
•
특정 프로세스의 실행 여부 : 핵심 서비스가 중단되었는지 확인.
•
메모리 부족 : 시스템 메모리가 특정 임계값 이하로 떨어지면 경고 또는 재부팅.
•
파일 시스템 무결성 : 파일 시스템에 오류가 없는지 주기적으로 검사.
•
커널 패닉 감지 : panic = 1 옵션처럼, 커널 패닉 발생 시 하드웨어 워치독을 통해 즉시 재부팅을 유도.
Odroid M1S 내 Watchdog 확인
제가 리서치한 서버 장비는 Odroid M1S입니다. M1S의 경우 Rockchip RK3566 프로세서가 사용되었고, 이 칩에는 Hardware watchdog timer가 내장돼 있는 것을 확인할 수 있었습니다. 확인한 정보는 다음과 같습니다.
•
M1S 공식 홈페이지 제품 스펙
•
해당 파일 내에 rk3566-odroid-m1s.dts 파일에서 include 돼 있는 파일 중 rk3568.dtsi 파일 내에 watchdog@fe600000 에 Watchdog Timer 관련 노드가 정의되어 있는 것을 확인할 수 있습니다.
3. Odroid - Ubuntu 24.04
여기서부터 리서치의 본문입니다.
안정적인 무인 운영을 위해 서버의 운영체제의 안정성 역시 중요합니다. 때문에 기본적으로 제공되는 Ubuntu 20.04 을 Ubuntu 24.04로 업그레이드 하여 운영하고자 했습니다. m1s 에서 사용할 수 있는 운영체제는 아래의 링크에서 구할 수 있습니다.
ubuntu-24.04-server-odroidm1s-20240313.img.xz 이미지로 빌드한 오드로이드에서 watchdog를 설치하고 kernel panic을 일으켜 테스트를 해보았을 때 제대로 재부팅이 되지 않는 부분을 확인하였습니다.
# 커널 패닉 테스트
echo c | sudo tee /proc/sysrq-trigger
Shell
복사
여기서는 몇 가지 이유가 있는 부분을 확인하였습니다.
watchdog 설정과 sysctl
AI의 조언을 받아 여러 테스트를 해보았지만, watchdog 설정에는 패닉 관련 설정에서는 특별히 대응이 되지 않은 부분을 확인하였습니다. 다른 방향으로 리서치해보고 sysctl 설정을 통해 패닉이 일어날 경우 재부팅 옵션을 설정할 수 있었습니다. 또한 기본적으로 /etc/sysctl.conf 파일에는 kernel.panic 에 대한 값이 기본 설정이 돼 있지 않아, /proc/sys/kernel/panic 에는 0이 입력돼 있습니다. 이 경우 커널 패닉이 일어날 경우 재부팅 없이 대기 상태로 유지됩니다.
# 커널 패닐 발생 시 재부팅 옵션 (1초 뒤 재부팅)
echo "kernel.panic = 1" >> /etc/sysctl.conf
Shell
복사
위와 같이 kernel.panic 옵션을 sysctl.conf 파일에 입력 후 재부팅하거나 /proc/sys/kernel/panic 파일에도 동일한 숫자 값을 넣어주면 됩니다.
•
/etc/sysctl.conf : 부팅 시 /proc/sys/kernel/panic 파일 초기화
•
/proc/sys/kernel/panic : 커널 패닉이 일어났을 때 재부팅할 시간을 초 단위로 입력합니다.
위의 두 파일의 값을 확인한 뒤, 제대로 설정됐다면 패닉이 발생한 뒤 몇 초 뒤에 재부팅이 이루어질지 설정할 수 있습니다.
Ubuntu 24.04 Kernel Issue
grep CONFIG_LOCKUP_DETECTOR /boot/config-$(uname -r)
grep CONFIG_SOFTLOCKUP_DETECTOR /boot/config-$(uname -r)
grep CONFIG_HARDLOCKUP_DETECTOR /boot/config-$(uname -r)
Shell
복사
ubuntu 24.04에는 기본적으로 아래의 설정을 적용할 수 있는 것으로 알고 있습니다. 때문에 위의 명령어를 실행할 경우 아래와 같은 결과를 기대할 수 있습니다.
# 기대하는 결과값
CONFIG_LOCKUP_DETECTOR=y
CONFIG_SOFTLOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
Shell
복사
하지만 만약, CONFIG_SOFTLOCKUP_DETECTOR, CONFIG_HARDLOCKUP_DETECTOR is not set의 경우 커널에서 softlockup, hardlockup 감지 기능을 포함하고 있지 않음을 의미합니다. 그리고 odroid ubuntu 24.04 내에서 위의 명령어를 실행시키면, 아래와 같은 결과를 나타내어 감지 기능이 없음을 확인하였습니다.
CONFIG_SOFTLOCKUP_DETECTOR is not set
CONFIG_HARDLOCKUP_DETECTOR is not set
Shell
복사
그 결과로, 아래의 두 파일이 존재하지 않게 됩니다.
•
/proc/sys/kernel/hardlockup_panic
•
/proc/sys/kernel/softlockup_panic
또한 위의 두 파일을 임의로 생성해주거나, sysctl.conf 파일에 각 panic 설정을 해주어도 무의미하게 됩니다. 다만, 위의 두 파일이 생성되지 않는다고 해서 커널 패닉이 발생했을 때 재부팅이 이루어지지 않는 것은 아닙니다.
softlockup & hardlockup
각 lockup의 경우 특정 유형의 오류 상황을 커널 자체적으로 감지했을 때, 그 감지된 상황을 커널 패닉으로 승격시킬지 말지를 결정하는 스위치 입니다. 만약 이 파일들이 존재하고 1로 설정돼 있다면, 해당 유형의 락업이 발생했을 때 panic() 함수가 호출되어 커널 패닉이 유발됩니다.
특징 | Soft Lockup | Hard Lockup |
심각성 | 덜 심각 (해당 CPU 코어만 영향을 받음) | 더 심각 (해당 CPU 코어가 완전히 마비, 시스템 전체 영향) |
감지 시간 | 2 * watchdog_thresh (기본 20초) 이상 CPU 독점 | 1 * watchdog_thresh (기본 10초) 이상 인터럽트 무시 |
인터럽트 응답 | 응답 가능 | 응답 불가능 (NMI 포함) |
원인 | 커널 스케줄링 버그, 긴 루프, 스핀락 오용 등 | 심각한 커널 버그, 하드웨어 결함, 인터럽트 장기 비활성화 |
감지자 | hrtimer 기반 watchdog kthread | NMI 워치독 (Non-Maskable Interrupt) |
영향 | 시스템 성능 저하, 응답 지연 | 시스템 전체 무응답, 완전한 정지 |
/etc/sysctl.conf | kernel.softlockup_panic | kernel.hardlockup_panic |
아래는 각 Lockup에 대해 풀어서 요약한 내용입니다.
softlockup : 스케줄링 문제
커널 내부의 버그로 인해 특정 CPU가 커널 모드에서 2 * watchdog_thresh초 (기본값 20초) 이상 다른 태스크(심지어 다른 커널 태스크나 사용자 프로세스)에게 CPU 사용 기회를 주지 않고 무한 루프에 빠지거나 특정 작업에 너무 오랫동안 매달리는 상태를 말합니다.
hardlockup : 완전 마비 상태
커널 내부의 버그나 심각한 하드웨어 문제로 인해 특정 CPU가 커널 모드에서 1 * watchdog_thresh초 (기본값 10초) 이상 루프에 빠져 어떤 인터럽트(심지어 NMI - Non-Maskable Interrupt 포함)에도 응답하지 못하는 상태를 말합니다.
4. Conclusion
무인 지점의 서버를 관리할 때 커널 패닉과 같은 이슈가 발생한다면, 안정적인 서비스를 제공하지 못해 가용성에 치명적일 수 있습니다. 때문에 Linux 에서 제공하는 Watchdog 서비스를 활용하는 방법이 필요합니다.
기본적으로 Ubuntu 24.04와 같이 운영체제와 하드웨어 칩에는 Hardware watchdog timer와 watchdog 데몬을 지원합니다. 또한 Ubuntu 24.04에는 softlockup과 hardlockup을 설정할 수 있는 커널로 빌드돼 있어, 적절한 커널 패닉 이슈를 적절히 설정할 수 있습니다.
하지만 Odroid M1S의 경우 Hardware watchdog timer와 같이 칩에서 지원하는 설정과 별개로, softlockup, hardlockup을 지원하지 않는 커널로 빌드돼 있는 ubuntu 24.04를 지원하기 때문에 panic 설정으로만 커널 패닉 시 재부팅이 가능합니다. 또한 기본적으로 /etc/sysctl.conf 파일에 panic에 대한 기본 설정이 돼 있지 않아 패닉 발생 시 재부팅하지 않고 대기상태로 유지됩니다. 따라서 watchdog 서비스가 설치하는 것만으로는 커널 패닉 발생 시 재부팅이 일어나지 않습니다.
따라서, /etc/sysctl.conf 파일의 kernel.panic = (양수 숫자) 값을 입력해주어, 커널 패닉이 발생할 경우 몇 초 뒤 재부팅할 지 설정할 수 있습니다. 해당 설정으로 어느정도 커널 패닉에 대응할 수 있어, 무인 지점 운영에 안정성을 높일 수 있을 것입니다.