参考までに共有します。管理画面に「Updating」と表示されているが、実際には更新中ではなく、フォーラム自体は正常に動作している場合の対処法です。
Docker Manager による更新にはこれまで影響しませんでしたが、過去数バージョンでは、管理画面が常に Discourse の更新中を示しているため、CLI での更新を行わざるを得ませんでした。
私のフォーラムは小規模で、カスタムプラグインも使用していません。
この問題の解決策は、Redis キャッシュをフラッシュすることでした。
根本原因については共有できませんが、Discourse の更新プロセスに関する知識と理解の限界に直面したことは非常に苛立たしかったです（これは苦情ではなく、率直な告白です）。
これまで、アプリの再構築（rebuild app）は、ほぼあらゆる問題に対する信頼性の高い解決策でした。
Redis にはユーザーセッションなども格納されています。Redis を完全にフラッシュすると、すべてのユーザーがログアウトし、保留中の Sidekiq ジョブが削除されます。スケジュールされたジョブは、次の再起動後にのみ復元されます。
これは最終手段としてのみ行うべきであり、その場合でも、すべてをフラッシュするのではなく、問題となっている特定のキーが何かを確認することを強くお勧めします。これは、ネズミを退治したいからといって、建物全体に火を放つようなものです。
Redis を再起動することはできないでしょうか？Redis はインメモリデータベースなので、サーバー再起動などでデータが保持されないはずです。また、サーバー再起動は破壊的な操作ではなく、いつでも発生しうるものです。
それは誤りです。Redis はディスクに永続化されます。
あなたの洞察と専門知識に感謝します。
私が試したことは以下の通りです：
これが問題を解決した唯一の対応でした。
アナロジーは理解できます。
この問題をより深く理解し、解決するために、他にどのような対応が可能だったでしょうか？
はっきりさせておきますが、以下のコマンドが機能しなかったとおっしゃるのでしょうか？
cd /var/discourse
git pull
./launcher rebuild app
（どのように機能しなかったのでしょうか？これは標準的なインストールですか？）
git pull は実行しませんでした。ランチャーのビルドアプリは実行しました。
そのプロセスは正常に完了しましたが、管理パネルで更新が進行中であると認識された状態が解除されませんでした。
ありがとうございます。つまり、管理者パネルの更新が機能していないというご指摘ですね。実は、私の方もしばらく前から同様の問題が発生していました。正常に動作する方が良いでしょう。
free -h は何を返しますか？
app.yml で UNICORN_WORKERS は何に設定されていますか？
app.yml で db_shared_buffers は何に設定されていますか？
app.yml で db_work_mem はコメントアウトされていますか？
あなたのサーバーには何個の (v)CPU がありますか？
free -h の出力: 3.8Gi メモリ、1.7Gi 使用、134Mi 空き、1.0Gi 共有、buff/cache 2.0Gi、利用可能 788Mi
スワップ: 2.0Gi、290Mi 使用、1.7Gi 空き
UNICORN_WORKERS: 4
db_shared_buffers: 1GB
db_work_mem はコメントアウト済み、40MB に設定
2 vCPU 4GB RAM のインスタンスを実行しています。
ご質問ありがとうございます！
