申し訳ありませんが、専門家ではないので、またUIで「アップデート」をクリックしたところ、「コマンドラインから再構築を実行する」ように促され、それが失敗して、何が間違っているのかAIに伝えるためにbashの出力を貼り付けています。
「エラーは、Discourseアップデートが失敗したことを示しています。なぜなら、discourse-data-explorerプラグインは現在Discourseコアにバンドルされており、app.yml設定ファイルに個別のプラグインとして含めるべきではないからです。」
常に可能とは限りませんが、「覚悟してください、これは痛みを伴いますよ」のような警告があると嬉しいです。寿命が延びるかもしれません。
まさにそのことについて警告が表示されるはずでした。その後、コンテナを次のように再起動できます。
./launcher start app
そして、次のステップをよりゆっくりと検討できます。
まだコンテナを起動できる可能性があります。
おっしゃる通りです。
最初の再構築が失敗するとは思っていなかったので、不意を突かれました。
メッセージはありましたが、ログテキストの壁の中にあったため、問題を見つけられるという自信がありませんでした。何らかの不明瞭な例外がコールスタックに埋もれている可能性もありました。AIが教えてくれた後、それは一番下にすぐ近くにあることがわかりました。
ウェブマスターをパートタイムでやっていると、こうなるのでしょうね。
はい。それは少し不運でした。これは10年間で最も破壊的なアップグレードです。
はい。それは巨大なテキストの壁です。私はそれを約10年間見てきましたが、何を見るべきかを知るのはまだ難しいです。
残念ながらそうです！
「ai」を使用するときは、Ask.discourse.comを使用してください。
エラーが発生した場合、まず確認すべきはログです。ログを確認すれば、どこで問題が発生したのか、どのような問題が発生したのかを把握することができます。
ログを確認せずにエラーを修正しようとすると、問題がさらに悪化する可能性があります。そのため、エラーが発生した場合は、まずログを確認するようにしてください。
アップデートの複雑さは、特定のアップデートに依存するのではなく、アップデート前のフォーラムのバージョン、Postgres、Redis、およびすべてのプラグインのバージョンに大きく依存します。
したがって、アップデートが「痛みを伴う」かどうかを判断することは基本的に不可能です。
問題なく1.8から3.5へのアップデートを行ったこともあれば、3.2.1から3.2.2へのアップデートで数時間かかって修正したこともあります。
役立つかもしれないことの1つは、これが「予期された」問題である場合（つまり、コールスタックに埋もれていない場合）、ログ出力でそれを----で囲むことです。それを見つけやすくなります。
また、アップデート以来、私のバックアップが再び壊れてしまい、私には再び骨の折れる仕事に戻らなければなりません 
これは大変な経験でしたね。申し訳ありません。
あなたの場合、あまり慰めにはなりませんが、本当のことです。コマンドラインでの介入が必要なアップデートはまれです。
この問題を解決できたことを願っています！セルフホスティングしている場合は、何が起こるかわからないので、バックアップが必要です。
土曜日に、今回はask.discourseの助けを借りて、集中して取り組みました。
非標準のボリューム設定になっており、アップロードとバックアップがセカンダリディスクで行われていたことが判明しました。これは問題にはならなかったはずですが、データディスクを20GBから30GBに拡張した際に、ファイルシステムに通知するのを忘れていました！
それを修正し、数年分の余裕ができました。
ああ！それは大変でしたね！確かに高度な設定です。
解決できてよかったです。
このトピックは6日後に自動的に閉じられました。返信はもう許可されていません。