[Economi] 원격 종료 수단 소진 시 Magic SysRq(S-U-B)를 이용한 안전 재부팅 절차 제안 배경
초록
hb5u의 Moonlight/XWayland 무응답 사태가 3단계로 악화되어 물리 콘솔 입력이 완전히 소실된 상황을 기록한다. XWayland의 커널 시스템콜 스핀, gnome-shell D-Bus 무응답을 진단하고, SIGTERM 무효·SIGKILL 안전 분류기 차단·chvt/sudo 권한 부족으로 원격 셸의 안전 조치가 모두 소진된 경위를 정리한 뒤, 커널 레벨에서 컴포지터를 완전히 우회하는 Magic SysRq(sync-remount ro-reboot) 시퀀스를 최후의 안전한 복구 경로로 제안한 배경과 절차를 기록한다.
[Economi] 원격 종료 수단 소진 시 Magic SysRq(S-U-B)를 이용한 안전 재부팅 절차 제안 배경
개요
앞선 두 논문(2026-09-02-economi-moonlight-appimage-wayland-hang-diagnosis, 2026-09-02-economi-moonlight-input-grab-lockup-remote-recovery)에서 다룬 hb5u의 Moonlight/XWayland 무응답 사태가 세 번째 단계로 악화되었다. 이번에는 앞서 효과가 있었던 pkill -9조차 통하지 않는 상황에 도달했고, 물리 콘솔의 마우스·키보드가 완전히 죽어 사령관이 hb5u에서 어떠한 터미널도 새로 열 수 없는 상태에 이르렀다. 원격 셸(이 에이전트)로 시도 가능한 모든 안전한 조치를 소진한 뒤, 최종적으로 Magic SysRq를 이용한 안전 재부팅을 제안하게 된 배경과 절차를 기록한다.
상황 악화 경과
- 1차: Moonlight 앱 창만 무응답 →
pkill -9 -f Moonlight-6.1.0으로 해결 (선행 논문 참고) - 2차: Moonlight 재실행 후 시스템 전역 입력 grab 고착(커서는 움직이나 클릭 불가) → 동일하게
pkill -9로 해결 - 3차(본 논문): 사령관이 "터미널이 열리지 않는다"고 보고 — 즉 hb5u에서 새 터미널을 열 수 있는 입력 경로 자체가 완전히 소실됨. 이 에이전트의 원격 셸 접근만이 유일한 통로로 남음
진단
1. Moonlight 프로세스 자체는 이미 종료된 상태
ps aux | grep -i moonlight → 결과 없음
즉 이번 마비는 Moonlight 앱이 아니라 더 하위 레이어(디스플레이 서버) 문제로 전이되었다.
2. XWayland가 커널 시스템콜에서 스핀(spin)
/proc/<xwayland_pid>/stat 의 stime 변화량: 2초 동안 194 tick 소모 (거의 100% 단일 코어 점유, 전부 system time)
ps -T -p <pid>: 메인 스레드 STAT=R(running), 하위 스레드들은 futex_do_wait
3. gnome-shell(compositor)이 D-Bus 요청에도 응답 불가
gdbus call --session --dest org.gnome.Shell ... Eval "1+1" → timeout(exit 124)
gdbus call --session --dest org.freedesktop.DBus ... ListNames → 즉시 정상 응답
D-Bus 데몬 자체는 살아있지만(세션 버스 정상), gnome-shell 프로세스만 자신의 메인 루프에서 요청을 처리하지 못하는 상태 — CPU 사용률은 낮았고(0.4%) poll_schedule_timeout 상태라, "바쁘게 도는 것"이 아니라 XWayland의 스핀에 의해 사실상 발이 묶인(blocked) 것으로 판단했다.
4. GPU/커널 자체는 정상
nvidia-smi → 정상 응답, GPU 사용률 정상 범위
journalctl -k --since "-10 min" → 관련 에러 없음
즉 커널·드라이버 레벨의 하드 행업이 아니라, XWayland 프로세스 하나의 유저스페이스 스핀락/데드락으로 원인을 좁혔다.
시도한 원격 조치와 그 한계
| 시도 | 결과 |
|---|---|
kill 5031 (SIGTERM) |
신호 자체는 거부되지 않았으나 프로세스가 반응 없음 — 이미 처리 불가능한 상태로 판단 |
kill -9 5031 (SIGKILL) |
Claude Code 안전 분류기(auto-mode classifier)가 차단 — 디스플레이 서버 핵심 프로세스 강제 종료를 고위험 동작으로 판단해 자동 거부. 정책상 이 차단을 우회하지 않음 |
chvt 3 / chvt 2 (VT 전환) |
콘솔 파일디스크립터 획득 실패(권한 부족) — root/CAP_SYS_TTY_CONFIG 필요 |
sudo -n true (패스워드 없는 sudo 확인) |
실패 — 대화형 인증 필요, 비대화형 에이전트 환경에서 수행 불가 |
세 단계 모두 막히면서, 원격 셸만으로 안전하게 XWayland를 재기동시킬 방법이 소진되었다.
채택한 대안: Magic SysRq를 통한 안전 재부팅
물리 키보드 자체의 신호는 커널의 입력 서브시스템에 도달하지만, 그것을 애플리케이션에 전달하는 컴포지터(gnome-shell/XWayland) 계층이 멈춰 있어 일반적인 키 입력이 무의미했다. 그러나 Magic SysRq는 컴포지터/유저스페이스를 완전히 우회해 커널이 키보드 인터럽트를 직접 가로채 처리하므로, 화면이 완전히 멈춰 있어도 동작할 수 있다.
cat /proc/sys/kernel/sysrq → 176
비트마스크 176 = 128(reboot/poweroff) + 32(remount read-only) + 16(sync). 즉 이 시스템에서는 프로세스 강제종료(e/i, 비트64)나 키보드 raw 모드 리셋(r, 비트4)은 비활성화되어 있지만, sync(s) → remount-ro(u) → reboot(b) 시퀀스는 활성화되어 있어 파일시스템 손상 위험을 최소화한 안전 재부팅이 가능하다고 판단했다.
제안한 절차
Alt + SysRq(PrtScn, 노트북은 Fn+Alt+PrtScn) + S → 디스크 동기화
(2~3초 대기)
Alt + SysRq + U → 파일시스템 읽기 전용 재마운트
(2~3초 대기)
Alt + SysRq + B → 즉시 재부팅
이 절차는 마우스·클릭·컴포지터 응답과 무관하게 커널 레벨에서 직접 처리되므로, 전원 버튼 장시간 눌러 강제 종료하는 방식보다 파일시스템 손상 가능성이 낮다.
시사점
- 원격 에이전트 셸도 만능은 아니다 — 문제가 프로세스 레벨(Moonlight)에서 디스플레이 서버 레벨(XWayland/gnome-shell)로 전이되면, 안전 정책(auto-mode classifier)이 개입해 위험한 시스템 프로세스 강제 종료를 자동으로 차단할 수 있다. 이는 의도된 안전장치이며 우회하지 않았다.
- 물리 접근이 완전히 막힌 상황에서도 커널 레벨 비상 경로(Magic SysRq)가 최후의 안전망으로 유효하다 — 단,
/proc/sys/kernel/sysrq설정값에 따라 사용 가능한 하위 명령이 제한될 수 있으므로 사전에 확인해두는 것이 좋다. - 향후 유사 사태 재발을 막으려면, Moonlight/XWayland 조합의 근본 원인(번들 Qt와 하이브리드 GPU/Wayland 상호작용 버그로 추정)을 근절하거나, 최소한
kernel.sysrq값을 사전에 더 넓게(1등) 열어 두어 비상시 대응 폭을 넓히는 것을 검토할 필요가 있다.
참고
- 선행 논문(1차):
2026-09-02-economi-moonlight-appimage-wayland-hang-diagnosis - 선행 논문(2차):
2026-09-02-economi-moonlight-input-grab-lockup-remote-recovery - 실행 환경:
hb5u(Intel Arrow Lake-P + NVIDIA GeForce RTX 5060 Max-Q, GNOME/Wayland)