このスレッドには、アプリの起動に関する複数の問題が含まれていた
ZimaOS 1.4.1から1.4.2にアップグレードした後、元の投稿者は、Portainerを含む一部のアプリが自動的に起動しなかったことに気付きました。次のようなDockerの再起動ポリシーは unless-stopped および always 目に見える結果は変わりませんでしたが、ダッシュボードでアプリをクリックすると起動しました。
その後、別のユーザーたちから、関連はあるものの異なる症状が報告されました。あるグループでは、コンテナはすでに直接のWebアドレスからアクセスできたにもかかわらず、ZimaOSダッシュボードでは停止しているかのように表示されました。別のユーザーは後に、選択したコンテナが実際に起動に失敗していたことを確認しました。これは、アプリの起動時にSMBで接続されたボリュームのパスがマウントされていなかったためです。
ケース1：コンテナは動作していたが、ダッシュボードから開けなかった
あるユーザーは、4段階の手順を記録しました。ダッシュボードには最初にアプリが停止していると表示され、その後、利用できない可能性があるという警告が表示されました。提示されたリンクをクリックすると新しいブラウザーウィンドウが開き、アプリは正常に動作しました。同じアドレスとポートをブラウザーに直接入力しても動作しました。
IceWhaleチームは、この挙動を調査対象の一部として扱いました。このスレッドからは、Dockerの再起動ポリシーを変更すればこのダッシュボードの状態の問題が解決するとは判断できません。
ケース2：1人のユーザーでアプリの更新と設定変更に失敗
1.4.3を実行していた別の参加者は、RadarrとSonarrの更新中に一時的なエラーが発生し、設定の変更が適用されなかったと報告しました。その環境では、アプリを再インストールしても改善しませんでした。その後、参加者はレジストリミラーを変更すると再び設定を変更できるようになったと述べ、別途、該当するアプリフォルダーの所有者を、設定済みのUID 1000に合わせて復元しました。
これらはユーザーが報告した変更であり、すべての再起動失敗に対する普遍的な修正ではありません。Dockerデーモンの設定を編集したり、所有権を再帰的に変更したりするとホスト全体に影響する可能性があるため、スレッドの証拠を参加者の環境を超えて一般化すべきではありません。
ケース3：コンテナ起動時にSMBストレージの準備が整っていなかった
元の投稿者は後に、3つのコンテナについて具体的な原因を特定しました。それらのボリュームはSMB共有にマッピングされていました。ログには、SMBファイルシステムが利用可能になる前にコンテナが起動を試み、失敗して停止したままだったことが示されていました。その後に手動で起動すると動作したのは、その時点では共有がマウント済みだったためです。
これが、変更すると always へ unless-stopped それらのコンテナには効果がありませんでした。再起動ポリシーを変更しても、利用できないバインドマウントのパスをより早く準備することはできません。関連していた依存関係は、ストレージの準備状況と起動順序でした。
バージョン1.4.3で確認されたこと、確認されなかったこと
IceWhaleからの返信では、ユーザーに1.4.3をテストするよう求めていました。参加者の1人はダッシュボードの挙動が変わらなかったと述べ、元の投稿者は当初1.4.3で改善したと考えていましたが、後にSMBの起動順序に関する失敗を再現しました。別の返信では、アプリ管理サービスが最後に実行されていた状態を把握するため、まずアプリを起動する必要があると指摘されました。
したがって、このスレッドは1.4.3ですべての1.4.2の起動問題が解決したと一括して断定する根拠にはなりません。診断を分ける根拠にはなります。まずコンテナが本当に停止しているかを確認し、次にログとストレージの依存関係を調べてください。
よくある質問
URLではアプリが開くのに、ZimaOSでは停止中のように表示されるのはなぜですか？
そのパターンは、ダッシュボードの起動または状態報告の問題として現れました。サービス自体はすでに実行中で、設定されたアドレスとポートからアクセスできる状態だった可能性があります。
再起動後にSMB共有を使用するコンテナだけが失敗するのはなぜですか？
確認されたケースでは、SMBマウントの準備が整う前にそれらのコンテナが起動していました。共有が表示された後に手動で起動すると、正常に動作しました。
Dockerの再起動ポリシーを変更すると問題は解決しましたか？
いいえ。元の投稿者は両方をテストしました always および unless-stopped 影響を受けたコンテナを再作成せずに
