저는 리눅스의 뛰어난 안정성 때문에 이 운영체제를 사용하는 것을 좋아합니다. 하지만 24시간 내내 가동되는 제 홈 서버는 리눅스의 한계를 시험하는 듯했고, 최악의 순간에 시스템이 멈추는 현상을 여러 번 겪었습니다. 때로는 원격 서버를 다시 온라인 상태로 만들기 위해 수동으로 재부팅해야 했습니다.
여러분도 비슷한 상황을 겪고 있다면 주목하세요. 리눅스에는 바로 이런 상황에 딱 맞는 내장 시스템이 있습니다. 여기에 systemd의 서비스 복구 기능을 결합하면 물리적인 개입 없이도 작동하는 효율적인 2단계 충돌 복구 메커니즘을 구축할 수 있습니다.
리눅스에는 이미 내장된 복구 메커니즘이 있다
시스템을 보호하는 워치독(watchdog) 타이머
리눅스에는 watchdog(워치독)이라는 내장 기능이 있습니다. 이 기능은 시스템이 주기적으로 "정상 작동 중"이라는 신호를 보내는 원리로 동작합니다. 일정 시간 동안 신호가 들어오지 않으면 워치독은 시스템에 문제가 발생했다고 판단하고 재부팅을 트리거합니다. 이 기능은 1990년대 중반부터 리눅스에 존재해 왔으며, 주로 서버나 임베디드 시스템처럼 가동 중단이 허용되지 않는 환경에서 사용되어 왔습니다.
일부 시스템에서는 /dev/watchdog 장치 파일을 통해 워치독에 접근할 수 있고, 다른 시스템에서는 /dev/watchdog0일 수 있습니다. 프로세스가 이 파일에 값을 써야 카운트다운 타이머가 초기화됩니다. 프로세스가 쓰기를 멈추면 일반적으로 시스템이 얼었거나 무한 루프에 빠진 프로세스가 리소스를 고갈했다는 의미입니다. 이 경우 타이머가 만료되면서 재부팅이 트리거됩니다.
워치독에는 하드웨어 방식과 소프트웨어 방식(softdog) 두 종류가 있습니다. 하드웨어 워치독은 메인보드에 탑재된 메커니즘으로, 커널이 완전히 잠긴 상황에서도 시스템 재설정이 가능합니다. 반면 소프트웨어 워치독은 커널 내부에서 실행되며 추가 하드웨어가 필요 없지만, 커널 크래시가 발생하면 도움을 줄 수 없습니다.
| 유형 | 전용 하드웨어 필요 | 하드 커널 크래시 생존 | 적합한 용도 |
|---|---|---|---|
| 하드웨어 워치독 | 예 | 예 | 서버, 상시 가동 필수 시스템 |
| 소프트웨어(softdog) | 아니오 | 아니오 | 홈 서버, VM, 범용 시스템 |
소프트웨어 워치독은 대부분의 시스템에서 겪는 일반적인 멈춤 현상, 즉 부하 급증, 메모리 고갈, 무한 루프 프로세스 등에 효과적입니다. 다만 이 기능은 기본적으로 비활성화되어 있으며, 잘못 설정하면 불필요한 반복 재부팅이 일어날 수 있으니 주의해야 합니다. 그럼에도 저에게는 가장 마음에 드는 숨겨진 리눅스 기능 중 하나입니다.
몇 분 만에 자동 충돌 복구 설정하기
실제로 작동하는 워치독 설정 방법
softdog은 거의 모든 리눅스 배포판에서 작동하므로 새로운 하드웨어가 필요하지 않습니다. 먼저 아래 명령어로 모듈을 로드하세요:
sudo modprobe softdog
재부팅 후에도 softdog이 유지되도록 하려면 /etc/modules 파일(Debian/Ubuntu)을 열고 softdog을 새 줄에 추가한 뒤 저장합니다. 그다음 워치독 데몬을 설치하고 활성화합니다:
sudo apt install watchdog
sudo systemctl enable --now watchdog
이제 /etc/watchdog.conf 파일을 열어 다음 핵심 설정들을 확인해야 합니다:
| 설정 | 제어 항목 | 실용적인 시작 값 |
|---|---|---|
| interval | 시스템 체크인 주기 | 10초 |
| max-load-1 | 재부팅 전 로드 평균 상한선 | CPU 코어 수의 약 6배 |
| min-memory | 재부팅 전 최소 여유 메모리 | 약 512페이지(약 2MB) |
max-load-1의 로드 평균은 1분 기준입니다. 이 값은 장치에서 CPU 시간을 두고 경쟁하는 프로세스 수를 나타냅니다. 예를 들어 4코어 머신의 로드가 4.0이면 모든 코어가 가득 찬 상태입니다. 시스템이 멈추기 전에 발생할 수 있는 정상적인 부하 급증을 감안해 여유 공간을 확보할 수 있도록 코어 수의 6배 값을 사용하는 것이 안전합니다.
또한 min-memory는 메가바이트가 아닌 메모리 페이지 단위로 지정한다는 점에 유의하세요. x86_64 시스템에서 한 페이지는 일반적으로 4KiB이므로, 512페이지는 약 2MB의 여유 메모리에 해당합니다.
설정을 마친 후 systemctl status watchdog 명령으로 데몬이 실행 중인지 확인하고, journalctl -u watchdog 명령으로 활동 기록을 검토할 수 있습니다.
참고로 워치독 서비스를 중지한다고 해서 재부팅이 트리거되지는 않습니다. 데몬이 종료 시 /dev/watchdog을 깔끔하게 닫아 타이머를 안전하게 해제하기 때문입니다. 워치독이 실제로 시스템을 재부팅하는지 테스트하려면 지속적인 부하 급증 같은 실제 장애 상황을 시뮬레이션해야 합니다.
모든 크래시에 재부팅이 필요한 것은 아니다
systemd로 고장 난 서비스를 몇 초 안에 복구하기
시스템을 재부팅할 필요 없이 systemd가 몇 초 안에 처리할 수 있는 장애들이 많습니다. 예를 들어 서비스가 크래시되거나, 예기치 않게 종료되거나, 응답하지 않는 경우입니다. 원본 유닛 파일을 수정하지 않고도 설정을 적용해 모든 오류가 재부팅으로 이어지지 않게 할 수 있습니다. 아래 명령어에 서비스 이름을 추가해 실행하세요:
sudo systemctl edit [서비스명]
그다음 다음 내용을 추가합니다:
[Service]
Restart=on-failure
RestartSec=5
Restart=on-failure는 서비스가 오류 코드와 함께 종료될 때만 재시작이 일어나도록 보장하고, RestartSec=5는 실제 재시작 전 짧은 지연을 두어 빠른 재시작 루프를 방지합니다.
StartLimitIntervalSec과 StartLimitBurst를 조합하면 고장 난 서비스가 무한히 재시작되는 것을 방지할 수 있습니다. 크래시 루프를 막는 데 필수적인 설정이지만, systemd 내에서 실행되는 서비스에만 적용됩니다.
거의 모든 장애를 커버하는 2단계 복구 체계
워치독과 systemd 서비스 관리는 각각 단독으로는 완벽하지 않습니다. 하지만 함께 사용하면 거의 모든 상황을 처리할 수 있습니다.
| 장애 유형 | 복구 계층 | 예상 결과 |
|---|---|---|
| 서비스가 오류와 함께 종료 | systemd (Restart=on-failure) | 몇 초 내 서비스 재시작 |
| 서비스가 정상 종료했지만 종료되면 안 되는 경우 | systemd (Restart=always) | 몇 초 내 서비스 재시작 |
| 전체 시스템 멈춤 또는 부하 폭주 | 워치독 데몬 | 수동 개입 없는 자동 재부팅 |
systemd는 개별 서비스 장애를 포착하고 재시작하는 데 적합하며, 워치독은 그 위에서 전체 시스템을 감시하다가 systemd의 한계를 넘어선 문제가 발생하면 재시작을 트리거합니다.
이 조합은 문제가 발생할 때마다 직접 대응할 필요가 없다는 뜻이며, 서버 관리를 훨씬 수월하게 만들어 줍니다. 또한 대부분의 시스템 문제를 해결하는 데 도움이 되는 핵심 리눅스 명령어들도 함께 익혀두는 것을 추천합니다.