이 스레드는 애플리케이션 자동 시작 문제에 대한 불만으로 시작했지만, 이후 한 답변에서 더 심각한 고장 원인이 확인되었습니다. 즉, 시스템에서 해당 런타임 경로가 호환되지 않는 상황에서 systemd 오버라이드가 nvidia-container-runtime을 강제로 사용하도록 설정되어 Docker 자체가 시작되지 않을 수 있었습니다.
먼저 Docker가 시작되는지 확인하세요
서로 관련 없는 여러 앱이 재부팅 후 모두 실패한다면 각 애플리케이션을 수정하기 전에 Docker 서비스를 확인하세요. Docker의 Docker 데몬 문제 해결 문서에는 충돌하는 구성과 systemd 오버라이드로 인해 발생하는 데몬 시작 실패가 설명되어 있습니다.
ZimaOS App Store 요구 사항은 어떤 애플리케이션이 Docker 기반인지 파악하는 데 도움이 되며, 첫 Docker 앱 문서에서는 일반적인 ZimaOS 컨테이너 워크플로를 설명합니다. 여러 컨테이너에 동시에 영향을 미치는 문제라면, 서로 독립적인 9개의 애플리케이션 버그보다는 데몬 또는 런타임 계층의 문제일 가능성이 높습니다.
재시작 정책만이 전부는 아닙니다
Docker의 Docker 재시작 정책 문서에 따르면 재시작 정책은 중지된 컨테이너에 대해 데몬이 수행할 작업을 제어합니다. Docker 데몬 자체가 정상적으로 시작되지 않으면 재시작 정책은 도움이 되지 않습니다.
NVIDIA 런타임 수정 방법은 시스템별 해결책이었습니다
한 기여자는 nvidia-container-runtime을 명시적으로 추가한 Docker systemd 오버라이드를 비활성화했습니다. 재부팅 후 Docker는 다시 실행되었지만, NVIDIA GPU 지원은 더 이상 해당 오버라이드를 통해 구성되지 않았습니다.
NVIDIA의 NVIDIA Container Toolkit은 현재 nvidia-ctk runtime configure --runtime=docker를 사용해 Docker를 구성한 다음 Docker를 재시작할 것을 권장합니다. 이는 중요한 맥락입니다. 오래된 커뮤니티 스레드에서 사용된 오버라이드 파일 이름 변경 방법을 NVIDIA 런타임을 구성하거나 제거하는 현대적인 보편적 방법으로 간주해서는 안 됩니다.
시스템 파일을 수정하기 전에 여유 공간을 확인하세요
이후 한 사용자가 오버라이드 이름을 변경하려 했지만 No space left on device 오류를 받았습니다. 이는 별개의 근본 원인이므로 먼저 해결해야 합니다. ZimaOS 1.5 변경 사항에서는 ZimaOS 변경 내용에 대한 버전 정보를 제공하며, 업데이트 후 호스트 전체에 문제가 발생한 경우 ZimaOS 문제 해결 절차가 유용합니다.
더 안전한 진단 순서
- Docker가 활성 상태인지 확인하고 최근 로그를 검토합니다.
- 시스템 디스크가 가득 차지 않았는지 확인합니다.
- 데몬이 정상 상태가 된 후에만 컨테이너 재시작 정책을 확인합니다.
- 로그에 NVIDIA 런타임 로드가 언급되면 변경하기 전에 현재 런타임 구성을 확인합니다.
- 사용자 지정 systemd 오버라이드를 수정하기 전에 백업합니다.
요점
원본 스레드만으로는 모든 ZimaOS 1.4.3 자동 시작 문제가 같은 원인으로 발생했다고 단정할 수 없습니다. 한 시스템에서는 NVIDIA Docker 런타임 오버라이드로 인해 데몬이 정상적으로 시작되지 않았고, 다른 시스템에서는 해결을 시도하는 과정에서 시스템 디스크가 가득 찬 사실이 드러났습니다. 과거의 오버라이드 우회 방법을 적용하기 전에 Docker 데몬과 저장 공간 상태를 먼저 진단하세요.
