임베디드 Linux 워치독: keepalive 전 상태 확인·타임아웃 설계

워치독 장치가 열려 있고 주기적으로 WDIOC_KEEPALIVE를 호출한다는 사실만으로 제품의 센서 수집과 핵심 작업이 정상이라는 뜻은 아닙니다. 임베디드 Linux 게이트웨이에서는 메인 루프만 살아 있고 센서 읽기 스레드가 멈출 수 있습니다. 이 글은 Linux 커널 워치독 사용자 API를 바탕으로 언제 ping을 보낼지를 정하는 방법을 설명합니다. 아래 예제는 실제 워치독 장치를 열지 않는 순수 C 판단 함수라 개발 PC에서 재부팅 위험 없이 시험할 수 있습니다.

1. 워치독이 관찰하는 것은 무엇인가

커널 문서에 따르면 /dev/watchdog을 열면 장치가 활성화되고, 일정 시간 안에 사용자 공간에서 알림이 오지 않으면 시스템이 재시작될 수 있습니다. 알림은 장치에 데이터를 쓰거나 지원되는 드라이버에서 WDIOC_KEEPALIVE ioctl로 보낼 수 있습니다. 하지만 장치 드라이버마다 지원 기능과 종료 동작이 다릅니다. 따라서 ping이 성공했다와 제품 기능이 정상이다를 같은 상태로 기록하면 장애를 놓칩니다.

예를 들어 30초 워치독에 10초마다 무조건 ping하는 프로그램은 센서가 5분째 응답하지 않아도 재시작을 막습니다. 센서 실패 시 재시작이 정답인지부터 제품 요구사항으로 결정하고, 재시작이 필요한 장애라면 마지막으로 성공한 센서 읽기와 핵심 작업의 진행 시각을 함께 확인해야 합니다. 단순히 스레드가 존재하는지만 보지 말고 새 작업이 실제로 완료된 시각을 기록합니다.

2. 장치가 수용한 타임아웃 확인

WDIOC_SETTIMEOUT을 지원하는 드라이버는 요청한 초를 그대로 쓰지 않을 수 있습니다. 커널 문서의 예시에서도 45초 요청이 하드웨어 제약 때문에 60초로 적용될 수 있습니다. WDIOC_GETTIMEOUT으로 적용된 값을 읽고, 해당 값보다 짧은 ping 주기와 센서 상태 허용 시간을 설계하세요. WDIOC_GETSUPPORT로 지원 기능을 확인하고 설정 ioctl의 반환값을 처리해야 합니다. SETTIMEOUT 실패를 무시한 채 요청 값이 적용됐다고 표시하면 진단을 왜곡합니다.

항목	예시	검토할 점
실제 워치독 시간	30초	`GETTIMEOUT`으로 읽은 값이며 장치별로 다릅니다.
평소 판단 주기	5초	스케줄 지연이 있어도 실제 시간보다 충분히 짧게 둡니다.
센서 상태 허용 시간	12초	센서 정상 주기와 재시도 시간을 합쳐 제품 요구에 맞춥니다.
장애 조치	ping 중단 또는 별도 복구	일시적 통신 장애를 즉시 재부팅할지 정책으로 결정합니다.

위 숫자는 설계 예시일 뿐 커널의 고정 권장값이 아닙니다. 실제 장치의 타임아웃, 부팅 시간, 데이터 손실 허용 범위와 장애 재현 시험을 거쳐 결정해야 합니다. 애플리케이션이 재시작돼도 원인이 해결되지 않는 장애에는 재부팅 반복을 막을 별도 조치가 필요합니다.

3. 상태 기반 ping 판단 함수

다음 C 코드는 단조 증가 시각(밀리초)을 받는다고 가정합니다. 센서와 작업의 성공 플래그가 모두 참이고, 두 성공 시각이 현재보다 미래가 아니며, 둘 다 허용 시간 이내일 때만 ping을 허용합니다. 실제 장치를 열거나 ioctl을 호출하지 않습니다. 입력 시각은 실기에 옮길 때 CLOCK_MONOTONIC 같은 단조 시계에서 얻고, 하위 시스템들이 같은 기준으로 기록해야 합니다.

watchdog_policy.c로 저장한 뒤 gcc -std=c11 -Wall -Wextra -Werror watchdog_policy.c -o watchdog_policy로 빌드하세요. Linux에서는 ./watchdog_policy, Windows PowerShell에서는 .\watchdog_policy.exe로 실행합니다.

#include <stdbool.h>

#include <stdint.h>

#include <stdio.h>

typedef struct {

uint64_t now_ms;

uint64_t sensor_last_ok_ms;

uint64_t worker_last_ok_ms;

bool sensor_ok;

bool worker_ok;

} Health;

/* Pure policy: this function never opens or pings a real watchdog. */

static bool may_ping(const Health *h, uint64_t max_age_ms) {

if (h == NULL || max_age_ms == 0 || !h->sensor_ok || !h->worker_ok)

return false;

if (h->now_ms < h->sensor_last_ok_ms || h->now_ms < h->worker_last_ok_ms)

return false;

return h->now_ms - h->sensor_last_ok_ms <= max_age_ms &&

h->now_ms - h->worker_last_ok_ms <= max_age_ms;

}

int main(void) {

Health h = {12000, 11000, 11500, true, true};

if (!may_ping(&h, 3000)) return 1;

h.sensor_last_ok_ms = 9000; /* Exactly at the boundary. */

if (!may_ping(&h, 3000)) return 2;

h.sensor_last_ok_ms = 8999; /* One millisecond stale. */

if (may_ping(&h, 3000)) return 3;

h.sensor_last_ok_ms = 11000;

h.worker_ok = false;

if (may_ping(&h, 3000)) return 4;

h.worker_ok = true;

h.worker_last_ok_ms = 12001; /* Invalid future sample. */

if (may_ping(&h, 3000)) return 5;

h.worker_last_ok_ms = 11500;

if (may_ping(&h, 0)) return 6;

puts("PASS: healthy, boundary, stale, worker fault, future, zero limit");

return 0;

}

예상 출력:

PASS: healthy, boundary, stale, worker fault, future, zero limit

경계값 테스트는 정확히 3,000ms 지난 성공을 허용하고 3,001ms는 거부합니다. 실패 플래그, 미래 시각, 허용 시간 0도 ping을 거부합니다. 64비트 밀리초를 쓰더라도 시스템 시계가 역행하는 데이터 혼합을 막기 위해 미래 시각을 별도로 확인합니다. 타임스탬프를 갱신하는 작업은 실제 성공 후에만 수행하고, 여러 스레드가 공유한다면 동기화가 필요합니다.

4. 실제 장치에 연결할 때의 경계

제품 코드에서는 판단 결과가 참일 때만 열린 워치독 파일 기술자에 ioctl(fd, WDIOC_KEEPALIVE, 0)를 호출하고 반환값을 검사합니다. 커널 문서는 이 ioctl이 지원 드라이버에서 장치에 쓰는 ping과 같은 목적이라고 설명합니다. 예제의 may_ping()은 정책만 시험하며 실제 ioctl 성공, 하드웨어 리셋, 장치 드라이버 동작을 검증하지 않습니다. 실기에서는 테스트용 보드와 복구 가능한 환경에서 ping 중단·프로세스 종료·부팅 후 원인 기록을 별도로 검증하세요.

닫기 동작에도 주의가 필요합니다. 드라이버에 따라 닫을 때 정지할 수 있고, Magic Close나 nowayout 설정이 적용되면 다르게 동작합니다. 워치독 모듈 파라미터 문서는 nowayout이 시작된 워치독을 멈출 수 없도록 하는 옵션임을 설명합니다. 운영 보드의 드라이버와 설정을 확인하지 않고 “프로세스가 종료되면 반드시 재부팅된다”라고 가정하지 마세요. 커널 문서 자체도 드라이버 구현 차이를 명시합니다.

공식 참고: Linux 커널 워치독 사용자 API, Linux 커널 워치독 모듈 파라미터.