このスレッドはアプリケーションの自動起動に関する苦情として始まりましたが、後の返信で、より深刻な障害モードが明らかになりました。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 デーモンとストレージの状態を診断してください。
