커뮤니티 솔루션

ZimaOS 1.4.3에서 Docker 데몬에 연결할 수 없음: 수동 재시작 및 1.4.4의 수정 사항

An August 2025 ZimaBoard 832 thread where ZimaOS 1.4.3 stopped starting Docker automatically after upgrade. IceWhale called it a known Docker-service issue and provided a manual restart command. The user confirmed the command worked, but the failure returned after reboot. ZimaOS 1.4.4 later fixed insufficient Docker startup timing.

이 출처 스레드에서는 버전에 따른 결론이 명확합니다. ZimaBoard 832를 ZimaOS 1.4.3으로 업그레이드한 후 Docker가 자동으로 시작되지 않았고, App Store에서 새 앱을 설치할 수 없었으며 기존 앱도 실행할 수 없었습니다. Zima-Giorgio는 팀에서 Docker 서비스 문제를 인지하고 있다고 밝혔으며 임시 수동 재시작 명령을 제공했습니다.

원 작성자는 재시작 명령으로 당면한 문제가 해결되었지만 호스트를 재부팅할 때마다 Docker가 다시 실패했다고 보고했습니다. IceWhale의 다음 릴리스에서 누락된 원인이 밝혀졌습니다. ZimaOS 1.4.4는 서비스 시작 간격이 충분하지 않아 발생한 Docker 시작 실패를 공식적으로 수정했습니다.

이 문제는 1.4.3 업그레이드 직후 발생했습니다.

출처의 사용자는 다음과 같이 보고했습니다.

  • Prowlarr 업데이트가 멈췄습니다.
  • 기존 앱이 실행되지 않았습니다.
  • 새 App Store 설치가 실패했습니다.
  • UI에는 Docker 데몬에 연결할 수 없다고 표시되었습니다.
unix:///var/run/docker.sock에서 Docker 데몬에 연결할 수 없다는 메시지가 표시된 ZimaOS App Store 설치 대화 상자
대시보드가 다음 경로를 통해 Docker에 연결하지 못했습니다. /var/run/docker.sock애플리케이션 설치 및 시작을 차단했습니다.

IceWhale은 이를 알려진 Docker 서비스 문제라고 설명함

8월 26일, Zima-Giorgio는 팀에서 이 문제를 알려진 Docker 서비스 문제로 보고 있으며 수정 사항을 배포할 예정이라고 밝혔습니다.

그는 다음과 같은 임시 공식 해결책을 제시했습니다.

sudo -i
systemctl restart docker docker.socket

이 명령은 해당 1.4.3 출처 사례에 대한 IceWhale의 당시 공식 안내입니다.

원 작성자가 수동 Docker 재시작이 작동했다고 확인함

사용자는 CLI에서 root 권한으로 Docker를 다시 시작하자 당면한 문제가 완전히 해결되었다고 답변했습니다. 이는 추측에 기반한 해결책이 아니라, 출처에서 확인된 성공 사례입니다.

그러나 같은 사용자가 이후 ZimaBoard를 재부팅하자 Docker가 다시 자동으로 시작되지 않았습니다.

Docker가 정상적으로 작동하지 않을 때 대시보드에 앱이 시작된 것으로 표시될 수 있음

재부팅 후 Jellyfin이 시작된 것처럼 표시되지만 시스템 위젯에는 실제 앱 CPU 또는 RAM 활동이 없다고 나타나는 ZimaOS 대시보드
재부팅 후 Docker 서비스가 애플리케이션의 실제 런타임 상태를 복원하지 못했는데도 앱 타일이 활성 상태로 표시될 수 있었습니다.

Docker를 다시 시작하면 실제 앱 상태가 복원됨

Docker를 다시 시작한 후 Jellyfin의 실제 상태와 복원된 시스템 리소스 활동을 보여 주는 ZimaOS 대시보드
Docker를 다시 시작한 후 UI에 앱의 실제 상태가 반영되었고 사용자는 Jellyfin을 정상적으로 시작할 수 있었습니다.

수동 앱 재시작으로 다음 재부팅 문제가 안정적으로 해결되지는 않았습니다.

Zima-Giorgio는 일부 보고에서 각 앱을 수동으로 시작하고 재시작하면 이후 재부팅 동작에 도움이 될 수 있다고 언급했습니다. 원 게시자는 이 방법을 테스트했지만 재부팅 후에도 동일한 잘못된 시작 상태가 계속 나타났습니다.

따라서 앱별 재시작을 이 소스의 최종 해결책으로 제시하지 않는 것이 중요합니다.

ZimaOS 1.4.4에서 Docker 시작 시간 문제가 수정되었습니다

IceWhale의 공식 1.4.4 릴리스 노트에는 다음이 포함되어 있습니다.

  • 시작 후 앱이 로딩 상태로 남아 있던 문제에 대한 수정
  • Docker 서비스 시작 간격이 부족해 시작 실패를 일으키던 문제에 대한 수정
  • 추가적인 애플리케이션 상태 및 설치 카드 수정 사항

Docker 서비스 시작 시간, 로딩 상태 앱, 설치 카드 및 관련 시작 동작에 대한 ZimaOS 1.4.4의 수정 사항은 ZimaOS 1.4.4 Docker 시작 수정 사항을 참조하세요.

현재 사용자는 systemctl restart를 영구적인 해결책으로 여기지 마세요

최신 ZimaOS 릴리스에서 재부팅 후 Docker 데몬이 반복적으로 실패한다면, 현재 서비스, 저장 공간, 런타임 또는 구성에 문제가 있음을 의미합니다. Docker를 재시작하는 것은 진단을 위한 조치일 수 있지만, 부팅할 때마다 수동 재시작을 당연한 절차로 만들기 전에 실제 실패 원인을 수집해야 합니다.

현재 유용한 증거는 다음과 같습니다.

  • systemctl status docker.service;
  • journalctl -u docker.service;
  • 시스템 디스크의 여유 공간
  • 최근의 GPU/런타임 오버라이드 또는 호스트 수정 사항
  • 현재 사용 중인 정확한 ZimaOS 버전입니다.

비슷한 증상이라도 근본 원인은 다를 수 있습니다

또 다른 1.4.3 논의에서는 사용자 지정 NVIDIA 런타임 오버라이드가 systemd 구성에 남아 있어 Docker가 실패한 사례를 다뤘습니다. 이는 이 소스 스레드의 시작 시간 문제와는 다른 원인입니다.

로그에서 특정 오버라이드가 실제로 데몬을 중단시키는 것으로 나타난 경우가 아니라면 서비스 오버라이드 파일을 삭제하지 마세요.

Docker 데몬 1.4.3 FAQ

IceWhale이 공식적으로 Docker 수동 재시작 방법을 제공했나요?

예. Zima-Giorgio가 게시했습니다. systemctl restart docker docker.socket 임시 1.4.3 우회 방법으로요.

소스의 사용자가 정상적으로 작동했다고 확인했나요?

예, 현재 부팅에 대해서는 그렇습니다. 재부팅 후 문제가 다시 발생했습니다.

제품 차원의 시작 문제가 문서화된 릴리스는 무엇인가요?

ZimaOS 1.4.4에서는 Docker 서비스 시작 시간이 부족해 시작 실패를 일으킬 수 있던 문제가 수정되었습니다.