[Economi] Moonlight AppImage 행업 재발 방지 — Watchdog 자동종료 + 격리(Xephyr) 테스트 방식

개요

앞선 4편의 논문(2026-09-02-economi-moonlight-appimage-wayland-hang-diagnosis 외 3편)에서 다룬 Moonlight-6.1.0 AppImage의 3단계 연쇄 행업 사고(앱 무응답 → 시스템 전역 입력 grab 고착 → XWayland 스핀락)는 매번 사람이 사후에 알아채고 강제 종료하는 방식으로 대응했다. 이번에는 같은 문제가 재발할 경우 사람이 개입하기 전에 자동으로 확산을 차단하고, 나아가 애초에 문제가 메인 데스크톱까지 번지지 않도록 격리된 환경에서 테스트할 수 있는 두 가지 보완 도구를 만들어 적용한 과정을 기록한다.

사전 확인: 버전 문제가 아님

먼저 사용 중인 v6.1.0이 최신 릴리스인지 확인했다. GitHub 릴리스 노트를 확인한 결과 v6.1.0이 최신이며, Wayland/XWayland/행업 관련 수정 사항은 해당 릴리스 노트에 언급되어 있지 않았다(참고로 macOS의 별개 이슈만 언급됨). 즉 업데이트로 해결될 문제가 아니며, 재발 가능성을 전제로 한 방어적 설계가 필요하다고 판단했다.

대응 1: QT_QPA_PLATFORM=xcb 상시 적용

1차 사고의 근본 원인이었던 네이티브 Wayland 렌더링 경로 대신, 기존에 검증된 XWayland 강제 우회 옵션을 이제 매 실행마다 자동 적용되도록 데스크톱 런처(~/Desktop/moonlight.desktop, ~/.local/share/applications/moonlight.desktop)의 Exec 라인을 래퍼 스크립트로 교체했다. 사용자가 별도로 환경변수를 기억하거나 터미널에서 실행할 필요가 없어졌다.

대응 2: 행업 감지 Watchdog (moonlight-watchdog.sh)

핵심 아이디어는, 3차례 사고 모두 "Moonlight가 멈춘 채 입력 grab을 계속 쥐고 있다가 더 심각한 상태로 번졌다"는 공통 패턴을 가진다는 점이다. 즉 Moonlight 프로세스 자체가 멈춘 시점에 바로 강제 종료할 수 있다면, grab 고착이나 XWayland 스핀락으로 확산되기 전에 문제를 끊을 수 있다.

감지 로직

진단 단계에서 사용했던 것과 동일한 지표를 재사용한다:

/proc/<pid>/wchan   → 프로세스가 커널 내부에서 대기 중인 지점
/proc/<pid>/stat 의 stime  → 커널 모드에서 소비한 CPU 틱

2초 간격으로 폴링하며, wchan이 정상 대기 상태(futex_do_wait, poll_schedule_timeout, ep_poll 등)가 아니면서 stime이 계속 증가하는 상태 — 즉 "정상적으로 쉬고 있는 게 아니라 뭔가에 갇혀 CPU를 계속 태우는 상태" — 가 20초 이상(폴링 10회) 지속되면 행업으로 판단해 kill -9로 Moonlight 프로세스를 강제 종료한다.

if [[ "\(wchan" != "futex_do_wait" && "\)wchan" != "poll_schedule_timeout" \
      && "\(wchan" != "ep_poll" && "\)wchan" != "0" ]] \
   && [ -n "\(prev_stime" ] && [ "\)stime" != "$prev_stime" ]; then
  stall_ticks=$((stall_ticks + 1))
else
  stall_ticks=0
fi

설계상 제한: XWayland는 건드리지 않는다

이 watchdog은 Moonlight 프로세스만 대상으로 한다. XWayland나 gnome-shell을 자동으로 강제 종료하는 로직은 의도적으로 넣지 않았다 — 디스플레이 서버 핵심 프로세스를 자동 판단으로 죽이는 것은 오탐 시 피해가 크고, 실제로 이전 사고에서도 이 동작은 Claude Code 안전 분류기가 에이전트의 수동 시도조차 차단했던 고위험 영역이다. Moonlight 하나만 자동으로 끊어주는 것만으로도, 지금까지의 사고 3건 중 최소 2건(1차, 2차)은 사람 개입 없이 초기 단계에서 차단됐을 것으로 판단된다. XWayland까지 번지는 3차 유형의 사고가 그래도 발생한다면, 기존에 확립된 대응 절차(에이전트 채팅 → !pkill -9 -f Xwayland → 휴대폰 SSH → Magic SysRq)를 그대로 따른다.

대응 3: 격리 테스트 환경 (moonlight-watchdog-isolated.sh)

Watchdog가 놓치는 경우(감지 임계값 이내에 사람이 먼저 입력 불능을 겪는 경우 등)에 대한 추가 방어선으로, Xephyr(중첩 X 서버) 안에서 Moonlight를 실행하는 방식을 추가했다.

Xephyr :2 -screen 1280x800 -resizeable -title "Moonlight (isolated)" &
DISPLAY=:2 QT_QPA_PLATFORM=xcb /path/to/Moonlight-6.1.0-x86_64.AppImage &

Moonlight의 모든 X 호출이 메인 GNOME/Wayland 세션이 아니라 이 중첩 서버를 향하게 되므로, 설령 포인터/키보드 grab이 걸리며 멈추더라도 그 grab은 Xephyr 창 안에서만 유효하다. 메인 데스크톱의 마우스·키보드는 계속 정상 동작하며, 최악의 경우 Xephyr 창만 닫으면(또는 watchdog이 cleanup() 트랩으로 Xephyr까지 함께 정리) 복구된다. 같은 hang-감지 로직을 이 안에서도 동일하게 적용해 이중으로 방어한다.

빈 디스플레이 슬롯(:2~:20)을 스캔해 자동 할당하고, trap cleanup EXIT로 스크립트 종료 시(정상 종료든 행업으로 인한 강제 종료든) Xephyr 프로세스까지 함께 정리되도록 했다.

사용 가이드

바탕화면/앱메뉴 아이콘은 기본값을 moonlight-watchdog.sh로 연결해두었다. 격리 모드는 필요할 때 수동으로 실행한다.

로그

두 스크립트 모두 ~/.local/share/moonlight-watchdog.log에 실행/종료/행업감지 이벤트를 타임스탬프와 함께 남긴다. 향후 재발 시 이 로그로 재발 빈도와 패턴(예: 특정 호스트 페어링에서만 발생하는지 등)을 추적할 수 있다.

시사점

1. 사후 대응(원격 진단 후 수동 kill)에서 사전 방어(자동 감지·자동 종료)로 한 단계 발전시켰다 — 동일한 진단 지표(wchan, stime)를 실시간 감시 로직으로 재활용한 것이 핵심이다.
2. 위험한 자동화(XWayland 강제종료 자동화)는 의도적으로 배제했다 — 자동화의 범위를 "확실히 안전한 것"(원인 프로세스 자체 종료)으로 제한하고, 더 위험한 조치는 여전히 사람의 판단에 맡기는 것이 안전한 자동화 설계 원칙이라고 본다.
3. 격리(Xephyr)는 감지 실패에 대한 이중 방어선이다 — 완벽한 감지 로직을 만들기보다,애초에 실패의 파급 범위를 좁히는 아키텍처적 해법이 더 견고할 수 있다는 점을 재확인했다.

참고

• 선행 논문: 2026-09-02-economi-moonlight-appimage-wayland-hang-diagnosis, 2026-09-02-economi-moonlight-input-grab-lockup-remote-recovery, 2026-09-02-economi-magic-sysrq-safe-reboot-after-remote-recovery-exhausted, 2026-09-02-economi-ish-tailscale-ssh-xwayland-final-resolution
• 실행 환경: hb5u (GNOME/Wayland, Moonlight-6.1.0-x86_64.AppImage)