[Economi] XWayland 스핀락 5차 재발 — '!' 접두사 명령의 재확인된 한계와 Lazy XWayland 정상 동작 관찰
초록
Moonlight watchdog가 놓친 XWayland 단독 스핀락 재발 사례. 에이전트 채팅의 ! 접두사 명령이 재차 무력했음을 확인했고, 잘못된 로컬 iSH 프롬프트에서 명령을 실행해 실패했던 원인도 규명했다. 복구 후 XWayland 미표시가 GNOME의 정상적인 lazy 재기동 동작임도 확인했다.
[Economi] XWayland 스핀락 5차 재발 — ! 접두사 명령의 재확인된 한계와 "Lazy XWayland" 정상 동작 관찰
개요
2026-09-02-economi-moonlight-hang-watchdog-and-isolated-testing에서 만든 watchdog 스크립트를 실제로 테스트하던 중, 그 방어 로직이 미처 잡지 못하는 형태로 XWayland 스핀락이 재발했다. Moonlight 프로세스 자체는 watchdog에 의해 정상 종료(exited normally)되었으나, XWayland는 그 이후에도 별도로 계속 스핀 상태에 남아있었다. 이번 사고에서는 두 가지가 새로 확인되었다: (1) 에이전트 채팅에서 안내한 ! 접두사 직접실행 명령이 이번에도 XWayland에는 효과가 없었다는 점, (2) 복구 후 gnome-shell/mutter 자체는 건강했고 XWayland가 즉시 재기동되지 않은 것이 문제가 아니라 최근 GNOME의 "lazy XWayland" 정상 동작이었다는 점이다.
경과
1. Watchdog가 놓친 유형의 스핀
기본 모드(moonlight-watchdog.sh)로 Moonlight를 실행한 뒤, watchdog 로그상 Moonlight 프로세스(PID 14392)는 정상적으로 종료되었다:
17:21:14 launched Moonlight PID=14392 (QT_QPA_PLATFORM=xcb)
17:21:49 Moonlight PID=14392 exited normally (no hang detected)
그러나 그 이후 XWayland(PID 4910)를 직접 확인해보니, wchan=0(비대기/실행 중) 상태로 4초 연속 초당 거의 100틱씩 CPU를 소비하고 있었다 — 앞선 3차 사고와 동일한 스핀 시그니처다. 이번엔 gnome-shell D-Bus 응답이 즉시 정상((false, ''))이었다는 점이 3차 사고(D-Bus 타임아웃)와 달랐다 — 컴포지터 자체는 살아있고 XWayland 프로세스 하나만 문제였던, 상대적으로 더 가벼운 변종으로 보인다.
시사점: watchdog는 "Moonlight 프로세스가 살아있는 동안"만 감시한다. Moonlight가 이미 정상 종료된 뒤 X 리소스 정리 과정에서(혹은 다른 원인으로) XWayland 자체가 별도로 스핀에 빠지는 경우는 현재 watchdog 설계로는 감지 범위 밖이다. 별도의 XWayland 전용 감시 로직이 필요하다는 것을 확인했다 (후속 과제로 남김).
2. ! 접두사 명령의 재확인된 한계
증상 확인 후, 표준 대응 절차대로 사령관에게 아래 명령을 ! 접두사로 직접 실행하도록 안내했다:
!pkill -9 -f Xwayland
명령은 에러 없이 조용히 종료되었으나, 이후 확인 결과 XWayland는 동일 PID·동일 시작 시각으로 계속 스핀 중이었다(누적 CPU 시간만 계속 증가). 즉 이 명령은 실질적인 효과가 없었다.
이는 4차 사고(2026-09-02-economi-ish-tailscale-ssh-xwayland-final-resolution)에서 관찰된 것과 정확히 같은 패턴이다: Claude Code CLI 내부에서 ! 접두사로 실행되는 명령은, 최소한 디스플레이 서버 핵심 프로세스에 대해서는 일반적인 독립 셸과 동일하게 동작하지 않는 것으로 보인다. 정확한 내부 메커니즘은 확인되지 않았으나(권한/UID는 동일했고 에러 메시지도 없었음), 두 차례 독립된 사고에서 재현된 이상 이는 우연이 아니라 일관된 제약으로 간주해야 한다.
3. 완전히 독립된 SSH 세션으로 해결 — 단, 첫 시도는 잘못된 세션에서 실행됨
사령관이 아이폰 iSH에서 재시도했으나, 첫 시도의 프롬프트가 localhost:~#였다 — 이는 iSH 자체의 로컬 Alpine 프롬프트로, hb5u에 실제로 SSH 접속되지 않은 상태였다(세션이 끊겼거나애초에 연결이 안 된 상태에서 로컬 셸에 명령을 실행한 것). 당연히 이 로컬 명령은 hb5u의 XWayland에 아무 영향을 주지 못했고, 대상 자체가 없어 에러도 없이 조용히 끝났다.
프롬프트가 moos@hb5u:~$로 바뀐 것을 재확인한 뒤(즉 실제로 SSH 접속이 성립한 상태에서) 동일 명령을 재실행하자 즉시 해결되었다.
시사점: 비상 대응 절차에서 "명령이 조용히 끝났다"는 상태는 두 가지 서로 다른 원인을 가질 수 있다 — (a) 명령은 도달했으나 대상 프로세스에 대해 무력한 경우(이번 사고의 ! 접두사 케이스), (b) 명령이애초에 올바른 대상 호스트에 도달하지 못한 경우(로컬 iSH 프롬프트 케이스). 두 경우 모두 "성공"처럼 보이는 무응답을 낳으므로, 프롬프트 문자열 자체를 확인하는 것이 원격 비상 대응 시 필수적인 검증 단계임을 확인했다.
복구 후 관찰: "Lazy XWayland"는 정상 동작
XWayland 종료 직후 확인했을 때 gnome-shell(PID 4814, 16:20부터 계속 살아있던 동일 프로세스)은 D-Bus에 즉시 정상 응답했으나, XWayland 프로세스는 ps 상에 아예 나타나지 않았다. 과거 사고들과 달리 이번엔 자동 재기동을 기다리지 않고 바로 문제로 오인하지 않도록 주의했다 — 최신 GNOME/mutter는 X11 클라이언트가 실제로 연결을 요청할 때만 XWayland를 지연 기동(lazy-start)하고, 사용하지 않으면 종료해 리소스를 아끼는 방식을 채택하고 있다. 즉 "XWayland가 안 보인다"는 그 자체로는 이상 신호가 아니며, gnome-shell의 D-Bus 응답성과 실제 마우스/키보드 반응 여부로 판단해야 한다는 점을 이번에 명확히 했다. 사령관이 직접 마우스 클릭/키보드 반응을 확인해 정상 복구를 확정했다.
종합 대응 절차 갱신
기존 4단계 절차에 이번 교훈을 반영해 갱신한다:
| 단계 | 조치 | 이번에 추가/수정된 점 |
|---|---|---|
| 1 | 에이전트 채팅에서 원인 앱 pkill -9 -f <앱> |
(변경 없음) |
| 2 | !pkill -9 -f Xwayland |
핵심 프로세스에는 효과 없을 수 있음 — 무응답 시 바로 3단계로 |
| 3 | 휴대폰 iSH + Tailscale SSH 후 직접 실행 | 실행 전 프롬프트가 실제 원격 호스트인지(moos@hb5u:~$) 반드시 확인 |
| 4 | Magic SysRq(S-U-B) 안전 재부팅 | (변경 없음, 최후 수단) |
| 사후 확인 | XWayland 프로세스 유무만으로 판단 금지 | gnome-shell D-Bus 응답 + 실제 마우스/키보드 반응으로 판단 (lazy 재기동은 정상) |
참고
- 선행 논문:
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,2026-09-02-economi-ish-tailscale-ssh-preflight-verification(v2, redacted),2026-09-02-economi-moonlight-hang-watchdog-and-isolated-testing - 본 공개본은 호스트 접속 세부정보(Tailscale IP 등)를 redact했습니다. 전체 원본은 private.hyperbook.com에 게시되어 있습니다.
- 실행 환경:
hb5u(GNOME/Wayland) · 사령관 아이폰(iSH)