스레드에는 앱 시작 문제가 하나만 있었던 것이 아닙니다.
ZimaOS 1.4.1에서 1.4.2로 업그레이드한 후 원 게시자는 Portainer를 포함한 일부 앱이 자동으로 시작되지 않는 것처럼 보였다고 밝혔습니다. Docker 재시작 정책 등 중지되지 않음 그리고 항상 눈에 보이는 결과는 바뀌지 않았지만 대시보드에서 앱을 클릭하면 앱이 시작되었습니다.
이후 다른 사용자들은 관련되어 있지만 서로 다른 증상을 보고했습니다. 한 그룹은 직접 웹 주소로 컨테이너에 이미 접속할 수 있었지만 ZimaOS 대시보드는 컨테이너가 중지된 것처럼 동작한다고 밝혔습니다. 이후 다른 사용자는 선택한 컨테이너가 실제로 실패했으며, 앱 시작 시 SMB 기반 볼륨 경로가 마운트되지 않았다고 확인했습니다.
사례 1: 컨테이너는 작동했지만 대시보드에서 열 수 없었던 경우
한 사용자는 네 단계의 과정을 기록했습니다. 대시보드는 먼저 앱을 중지된 상태로 표시한 다음, 앱을 사용하지 못할 수 있다고 경고했습니다. 제공된 링크를 따라가자 새 브라우저 창에서 애플리케이션이 정상적으로 작동했습니다. 같은 주소와 포트를 브라우저에 직접 입력해도 정상적으로 작동했습니다.
IceWhale 팀은 이 동작을 조사 대상의 일부로 다뤘습니다. 이 스레드만으로는 Docker 재시작 정책을 변경하면 이 대시보드 상태 문제가 해결된다는 결론을 내릴 수 없습니다.
사례 2: 한 사용자의 앱 업데이트 및 설정 변경 실패
1.4.3을 실행하던 다른 참가자는 Radarr와 Sonarr를 업데이트하는 동안 잠깐 오류가 발생했으며 설정 변경 사항이 적용되지 않았다고 보고했습니다. 해당 환경에서는 앱을 다시 설치해도 문제가 해결되지 않았습니다. 이후 참가자는 레지스트리 미러를 변경하자 설정 변경이 다시 적용되었다고 밝혔고, 별도로 관련 앱 폴더의 소유권을 구성된 UID 1000에 맞게 복원했습니다.
이는 모든 재부팅 실패에 대한 보편적인 해결책이 아니라 사용자가 보고한 변경 사항입니다. Docker 데몬 설정을 편집하거나 소유권을 재귀적으로 변경하면 호스트 전체에 영향을 줄 수 있으므로, 스레드의 근거를 해당 참가자의 환경을 넘어 일반화해서는 안 됩니다.
사례 3: 컨테이너가 시작될 때 SMB 스토리지가 준비되지 않음
원 게시자는 나중에 세 컨테이너의 구체적인 원인을 확인했습니다. 해당 컨테이너의 볼륨은 SMB 공유에 매핑되어 있었습니다. 로그에 따르면 SMB 파일 시스템을 사용할 수 있게 되기 전에 컨테이너가 시작을 시도했고, 실패한 뒤 중지된 상태로 남았습니다. 이후 공유 폴더가 마운트된 뒤 수동으로 시작하면 정상적으로 작동했습니다.
이는 변경하는 이유를 설명합니다 항상 에 중지되지 않음 해당 컨테이너에는 도움이 되지 않았습니다. 재시작 정책으로는 사용할 수 없는 바인드 마운트 경로를 더 일찍 준비할 수 없습니다. 관련된 종속성은 스토리지 준비 상태와 시작 순서였습니다.
버전 1.4.3에서 확인된 사항과 확인되지 않은 사항
IceWhale의 한 답변에서는 사용자들에게 1.4.3을 테스트해 달라고 요청했습니다. 한 참가자는 대시보드 동작이 그대로였다고 했고, 원 게시자는 처음에는 1.4.3이 도움이 되었다고 생각했지만 나중에 SMB 시작 순서 문제를 재현했습니다. 또 다른 답변에서는 앱 관리 서비스가 마지막 실행 상태를 알 수 있도록 앱을 먼저 시작해야 한다고 설명했습니다.
따라서 이 스레드는 1.4.3이 모든 1.4.2 시작 문제를 해결했다는 포괄적인 주장을 뒷받침하지 않습니다. 대신 먼저 컨테이너가 실제로 중지되었는지 확인한 다음 로그와 스토리지 종속성을 점검하는 진단 절차를 제시합니다.
자주 묻는 질문
URL로 앱을 열 수 있는데 ZimaOS에서는 중지된 것으로 표시되는 이유는 무엇인가요?
이 패턴은 대시보드 실행 또는 상태 보고 문제로 나타났습니다. 서비스 자체는 이미 실행 중이며 구성된 주소와 포트에서 연결할 수 있는 상태일 수 있습니다.
재부팅 후 SMB 공유를 사용하는 컨테이너만 실패하는 이유는 무엇인가요?
확인된 사례에서는 SMB 마운트가 준비되기 전에 해당 컨테이너들이 시작되었습니다. 공유 폴더가 표시된 후 수동으로 시작하면 정상적으로 작동했습니다.
Docker 재시작 정책을 변경하면 문제가 해결되었나요?
아니요. 원 게시자는 두 가지 모두 테스트했습니다 항상 그리고 중지되지 않음 영향을 받은 컨테이너를 해결하지 않은 채로
