핵심 결론: 먼저 ZimaCube의 네트워크 연결이 끊긴 것인지 OS 전체가 멈춘 것인지 판단하세요
“라우터에서 사라졌다”는 말은 NIC 문제처럼 들리지만, 이 글에서는 결국 더 중요한 단서가 나왔습니다. 모니터와 키보드를 연결했을 때 화면은 표시되었지만 키보드 입력에 시스템이 응답하지 않았습니다. 이는 DHCP 임대가 사라진 것뿐만 아니라 시스템이 멈춘 상태입니다. 이 차이를 파악하면 문제 해결 방법이 완전히 달라집니다.
다음 장애가 발생하기 전에 로컬 콘솔을 사용하세요
당분간 모니터와 키보드를 연결해 두세요. 원격 접속이 끊기면 전원을 껐다 켜기 전에 콘솔을 확인하세요. ZimaOS 콘솔 키를 눌러 화면이 업데이트되거나 입력을 인식하는지 확인해 보세요.
로컬 입력은 작동하지만 라우터에 더 이상 장치가 표시되지 않는다면 이더넷, DHCP 및 네트워크 서비스에 집중하세요. 로컬 입력도 작동하지 않는다면 화면을 캡처하고 이를 OS/커널/하드웨어 멈춤으로 간주하세요.
재부팅과 멈춤을 구분하려면 uptime을 사용하세요
uptime
last -x | head
journalctl -b -1 -p warning..alert
journalctl -b -1 -k복구 후 uptime으로 서버가 실제로 재부팅되었는지 확인할 수 있습니다. 이전 부팅 로그에는 강제 전원 차단 전에 발생한 커널 오류, 스토리지 시간 초과, OOM 종료 또는 드라이버 오류가 나타날 수 있습니다. 이전 부팅 로그에서는 저널의 부팅 항목을 선택하는 방법을 다룹니다.
라우터의 야간 예약을 근본 원인으로 단정하지 마세요
여러 사용자가 Wi-Fi 일정 또는 라우터 재부팅을 비활성화했음에도 장애를 재현했습니다. 따라서 “라우터가 Wi-Fi를 끈다”는 설명만으로는 충분하지 않습니다. 서버는 유선으로 연결되어 있었고, 이후 발생한 문제는 낮 시간에도 나타났습니다. 타임라인에 라우터 이벤트를 기록하되, 라우터를 원인으로 지목하기 전에 재현 가능한 상관관계를 확인해야 합니다.
복구 후 현재 이더넷 상태 확인
ip addr
ip route
ethtool YOUR_INTERFACE
dmesg | grep -i -E 'link|ether|nic|reset|timeout'현재 ZimaOS에서는 물리적 이더넷 링크 상태, 협상된 속도, 할당된 IP가 각각 별도로 표시됩니다. 다음 문제가 네트워크에만 발생한다면 라우터 포트 상태와 로컬 인터페이스 상태를 비교하세요. ZimaOS 네트워크 인터페이스에서 현재 네트워크 제어 기능을 제공합니다.
네트워크만 문제가 발생한 동안에도 콘솔이 명령을 받아들인다면, ethtool을 사용해 재부팅하지 않고 링크 상태, 협상된 속도 및 드라이버 정보를 확인할 수 있습니다. ethtool 네트워크 검사를 통해 링크만 끊긴 실행 중인 OS인지, 시스템 전체가 멈춘 것인지 구분할 수 있습니다.
반복적인 하드 리셋을 정상적인 복구 방법으로 사용하지 마세요
전원 버튼을 하루에 여러 번 누르면 파일 시스템과 데이터베이스가 손상될 위험이 있으며, 특히 대규모 전송이나 RAID 작업 중에는 더욱 그렇습니다. 콘솔이 멈췄고 정상적인 종료 방법이 없다면 강제 전원 사이클 한 번은 피할 수 없을 수 있지만, 가능하면 그 전에 증거를 수집하세요.
간헐적인 시스템 멈춤을 진단하는 동안에는 ZimaOS 백업이 특히 중요합니다.
안정성 테스트 중 변수 줄이기
비필수 앱을 일시 중지하고, 불필요한 USB/PCIe 장치를 비활성화하며, 정상 작동이 확인된 이더넷 경로 하나만 유지하고 동시에 수 테라바이트 규모의 마이그레이션을 진행하지 마세요. 멈춤 현상이 사라지면 작업 부하를 한 번에 하나씩 다시 추가하세요. 라우터, 클라이언트, 스토리지, 앱 설정을 모두 동시에 변경하는 것보다 훨씬 많은 정보를 얻을 수 있습니다.
ZimaOS 복구는 안정성 테스트에서 시스템 슬롯이나 설치에 문제가 드러났을 때 현재 사용할 수 있는 시스템 복구 범위를 제공합니다.
과거의 1.2.x 보고를 ZimaOS 1.7에 직접 적용해서는 안 됩니다
이 스레드는 2024년에 작성되었으며 IceWhale은 1.2.x 버전대에서 안정성 문제를 적극적으로 수정하고 있었습니다. 현재 ZimaOS는 커널, 네트워크, 메모리, 스토리지 및 파일 서비스가 여러 차례 변경되었습니다. 이 스레드는 진단 방법—콘솔과 네트워크, 재부팅과 멈춤, 로그와 추측의 구분—을 익히는 데 활용하되, 현재의 모든 야간 연결 끊김이 동일한 2024년 버그라고 단정하는 데 사용하지 마세요.
하드웨어를 의심해야 하는 경우
현재 안정 버전에서도 최소한의 앱과 정상 작동이 확인된 스토리지/네트워크 환경에서 계속 멈춘다면, 메모리 진단을 실행하고 온도, 전원, PCIe 장치 및 디스크/컨트롤러 오류를 점검하세요. 서로 다른 OS와 네트워크 환경에서 완전한 멈춤이 반복된다면 조사의 초점을 ZimaOS 자체보다 더 낮은 계층으로 옮길 수 있습니다.
ZimaCube 2 플랫폼은 기존 ZimaCube 하드웨어 케이스와 이후 플랫폼을 구분할 때 유용합니다.
FAQ
라우터에서 ZimaCube가 사라지는 이유는 무엇인가요?
네트워크만 장애가 발생한 것일 수도 있고, 재부팅 또는 완전한 시스템 멈춤일 수도 있습니다. 어느 경우인지 판단하기 전에 로컬 콘솔과 이전 부팅 로그를 확인하세요.
디스크 대기 모드 때문에 ZimaCube 전체가 사라질 수 있나요?
디스크 대기 모드가 서버 전체를 일시 중지한다고 단정해서는 안 됩니다. 키보드 입력과 네트워크가 모두 중단된다면 전체 시스템 멈춤으로 진단하세요.
매일 밤 재부팅을 예약해야 하나요?
예약된 재부팅은 불안정성을 가릴 수는 있지만 원인을 밝혀 주지는 않습니다. 재부팅을 영구적인 우회 방법으로 사용하기 전에 로그와 통제된 테스트를 활용하세요.
강제 재설정하기 전에 무엇을 수집해야 하나요?
콘솔을 촬영하고, 키보드 반응을 테스트하며, 라우터의 링크/DHCP 상태를 기록하고, 시간을 적어 두세요. 재부팅한 후에는 이전 부팅의 커널 로그와 경고 로그를 수집하세요.
대용량 파일 전송이 멈춤을 일으킬 수 있나요?
스토리지, 메모리, 드라이버 또는 발열 문제를 드러낼 수 있지만, 이를 뒷받침하는 로그가 없다면 전송 자체가 근본 원인이라고 볼 수 없습니다. 통제된 워크로드로 재현해 보세요.
