AI 기반 서비스

Today
-
Total
-
← 목록으로

DGX Spark 갑작스러운 셧다운 원인 분석 - PM2 무한 재시작의 함정

이창연•2026년 1월 23일

DGX Spark 갑작스러운 셧다운 원인 분석

어느 날 아침, 서버가 꺼져 있었다

2026년 1월 23일 아침. DGX Spark 서버가 꺼져 있었다. 새벽 1시 13분경 셧다운된 것으로 보였다.

처음엔 정전을 의심했다. 하지만 같은 네트워크의 miniPC는 57일째 정상 가동 중이었다. 정전이 아니라 Spark 자체의 문제였다.

로그 분석: 무슨 일이 있었나

타임라인

시간이벤트
1/22 19:45사용자가 sudo poweroff로 정상 종료
1/22 19:47서버 재부팅
1/22 21:00PM2 PID 파일 오류 시작
21:00~01:12PM2가 10초마다 재시작 시도 (4시간, 1,400회+)
1/23 01:12:39마지막 로그 기록
1/23 ~01:13시스템 비정상 종료
1/23 06:14수동 전원 ON

핵심 발견

last -x reboot shutdown 명령으로 확인해보니, 01:13 시점의 shutdown 기록이 없었다. 정상적인 종료 명령이 아니라 갑작스러운 전원 차단이었다.

reboot   system boot  6.14.0-1013-nvid Fri Jan 23 06:14   still running
reboot   system boot  6.14.0-1013-nvid Thu Jan 22 19:47   still running

1/22 19:47 부팅이 "still running"으로 남아있다는 것은, 그 세션이 정상 종료되지 않고 강제로 끊겼다는 의미다.

원인: PM2 무한 재시작 루프

journalctl로 확인한 결과, 21:00부터 PM2가 미친 듯이 재시작을 반복하고 있었다.

Jan 22 21:00:24 spark-home systemd[1]: pm2-lisyoen.service: Can't open PID file 
    /home/lisyoen/.pm2/pm2.pid (yet?) after start: No such file or directory

왜 이런 일이?

  1. 19:47 재부팅 후 PM2 데몬이 시작됐지만 .pm2/pm2.pid 파일 생성에 실패
  2. systemd가 "서비스가 제대로 안 떴네?"라고 판단하고 재시작
  3. 10초마다 재시작 시도 → 4시간 동안 1,400회 이상 반복
  4. restart counter가 66,000회 이상까지 누적

PM2가 관리하는 서비스 중 ipsearch-web과 lifeexp의 재시작 횟수:

lifeexp: 66,216회
ipsearch-web: 66,286회

이게 정상일 리가 없다.

죽음의 메커니즘

  1. PM2 무한 재시작 → CPU/메모리 리소스 지속 소모
  2. 프로세스 생성/종료 반복 → 시스템 부하 급증
  3. SBSA Watchdog 또는 BIOS Watchdog이 "시스템 응답 없음" 감지
  4. 강제 리셋 (shutdown 명령 없이 전원 차단)

DGX Spark에는 10초 타임아웃의 SBSA Generic Watchdog이 활성화되어 있다:

sbsa-gwdt sbsa-gwdt.0: Initialized with 10s timeout @ 1000000000 Hz, action=1. [enabled]

시스템이 10초 이상 응답하지 않으면 자동으로 리셋된다.

해결: PM2 systemd 서비스 수정

문제의 원본 설정

[Service]
Restart=on-failure
RestartSec=10
# StartLimit 설정 없음 → 무한 재시작 가능

수정된 설정

[Unit]
StartLimitIntervalSec=300   # 5분 동안
StartLimitBurst=10          # 최대 10회만 재시작 허용

[Service]
Restart=on-failure
RestartSec=10
ExecStartPre=/bin/rm -f /home/lisyoen/.pm2/pm2.pid  # 시작 전 PID 파일 정리

이제 5분 내 10회 이상 재시작하면 systemd가 "뭔가 심각하게 잘못됐다"고 판단하고 서비스를 중단한다.

추가 조치

  1. cluster 모드로 실행되던 Next.js 앱들을 fork 모드로 변경
  2. 재시작 카운터 리셋 (pm2 reset)
  3. PM2 상태 저장 (pm2 save)

NVIDIA 포럼에도 유사 사례 다수

나만 겪은 문제가 아니었다. NVIDIA Developer Forums에 비슷한 보고가 여럿 있다:

  • "DGX Spark constantly shut down after first set up" (2주 전)

    • idle 상태에서도 무작위 셧다운
    • shutdown 로그 없이 전원이 끊긴 것처럼 동작
  • "DGX spark keeps rebooting every 20-30 minutes" (2025년 11월)

    • 워크로드 없이도 자동 리부팅
    • 해결책: BIOS에서 Watchdog 비활성화 또는 recovery reflash
  • "Shutdown under high utilization during image generation" (최근)

포럼에서 밝혀진 원인들

  1. 메모리 부족: DGX Spark는 OOM 시 graceful하게 처리하지 못하고 크래시
  2. BIOS Watchdog: Advanced → Advanced → Watchdog에서 비활성화 가능
  3. 전원 어댑터: 정품 어댑터가 아니면 unexpected shutdown 가능
  4. 펌웨어 버그: thermal trip points 관련 ACPI 버그

교훈

1. systemd 서비스에는 반드시 StartLimit 설정

무한 재시작은 해결책이 아니라 더 큰 문제를 만든다.

2. PM2의 PID 파일 관리 취약점

PM2가 비정상 종료되면 PID 파일이 남거나 사라져서 다음 시작에 영향을 준다. ExecStartPre로 정리하는 게 안전하다.

3. Watchdog은 양날의 검

시스템 hang 시 자동 복구해주지만, 리소스 고갈 상황에서는 문제를 악화시킬 수 있다.

4. 재시작 카운터를 주기적으로 확인

pm2 jlist | jq -r '.[] | "\(.name): \(.pm2_env.restart_time)"'

수백 회 이상이면 뭔가 잘못된 것이다.

현재 상태

모든 서비스 정상 가동 중. 재시작 카운터 0으로 리셋 완료.

mcp-server: restart=2, status=online
zodiac-guesser: restart=0, status=online
lifeexp: restart=0, status=online
ipsearch-web: restart=0, status=online
claudeq-*: restart=0, status=online

다음에 비슷한 일이 생기면 무한 재시작 대신 서비스가 멈추고, 그때 원인을 파악할 수 있게 됐다.


DGX Spark를 24/7 서버로 운영하려면 이런 세부 설정에 신경 써야 한다. NVIDIA가 펌웨어 안정성을 계속 개선하고 있으니, 업데이트도 꾸준히 확인하자.