こんにちは。管理画面に接続しようとすると、真っ白な画面が表示されます。管理者権限を持っているにもかかわらず、例えばアップデートを行うことができません。
どうすればよいでしょうか?
ご協力ありがとうございます。
Muriel
セーフモードを試すか、コマンドラインでアップグレードすることをお勧めします。
更新: 正しいブートストラップ、破棄、2コンテナ設定での開始を行ったところ、報告されたバージョン番号が更新され、管理UIが再びレンダリングされるようになりました。
残りの投稿は後世のために残しておきます。
私も同様の問題を経験している可能性があります。管理インターフェースは読み込まれますが、上部のタブのみが表示され、メインのコンテンツセクションは空白になります。
ブラウザコンソールログ
ブラウザコンソールログを確認すると、次のようなエラーが表示されます。
[Error] Error: VM BUG: Target must be set before attempting to jump
vendor.xxxxx-xxxx.js
Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
エラースタック
[Error] Error: VM BUG: Target must be set before attempting to jump
at (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:131956)
at evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:69428)
at _execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
at execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
at rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
at (anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
at tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
at _renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
at _renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
at _revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
at invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
at flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
at flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
at _end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
at end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:156653)
at _runExpiredTimers (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:160801)
[Error] Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
at (anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1310)
at h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1311)
at (anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:3065)
at h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1375)
at requireModule (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:599)
at _extractDefaultExport (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:269780)
at resolveOther (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266326)
at resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266888)
at (anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262092)
at resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262185)
at resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262275)
at c (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:260192)
at (anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:258815)
at getRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:56849)
at fetchRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:267571)
at _getQPMeta (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63399)
at _hydrateUnsuppliedQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:64113)
at _prepareQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63271)
at normalizeQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38898)
at _generateURL (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38990)
at eA (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:202925)
at (anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49065)
at X (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:140358)
at T (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49044)
at eM (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:80191)
at flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:79868)
at (anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:70930)
at evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:65312)
at evaluateSyscall (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111047)
at evaluateInner (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110609)
at evaluateOuter (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110528)
at next (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121496)
at _execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121359)
at handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:112232)
at handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:114799)
at throw (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111583)
at evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:68993)
at _execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
at execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
at rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
at (anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
at tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
at _renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
at _renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
at _revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
at invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
at flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
at flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
at _end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
at (anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:155980)
アップグレードプロセス(2コンテナ)
当初、Discourse管理UIからアップグレードを完了しようとした際に問題が発生しました。Docker Managerを更新する必要があるというメッセージが表示されました。
Docker Managerを更新した後、問題が発生したため、SSHでサーバーに接続し、web_onlyのみを手動(2コンテナ)で更新しました。
cd /varian/discourse
git pull
./launcher bootstrap web_only
./launcher stop web_only && ./launcher start web_only
^^^^^^
⚠️ これは間違いです!下記のようにdestroyを使用してください。⚠️
奇妙なことに、/about.jsonパスでは、元のメールが3.4.0.beta4-devから3.5.0.beta1へのアップグレードに関するものだったため、私が開始したと思っていた3.4.0.beta4-devを実行していると表示されたままです。
gitログを再確認したところ、少なくともdiscourse_dockerは執筆時点で最新のコミット3715498fc188d60c0b579443383c4e973cf26f59にあるようです。
セーフモードは機能する
セーフモードについては認識していませんでしたが、すべてのクライアントサイドプラグインを無効にすると、問題は発生しないようです。
非公式のクライアントサイドプラグインのカスタマイズのみを無効にしても、問題は解決しません。各組み合わせを試して絞り込みました。
| オプション | 結果 |
|---|---|
no_unofficial_plugins |
|
no_plugins |
|
no_themes |
docker_managerを無効にしても効果がない
hooks/after_codeの下にあるdocker_managerプラグインをコメントアウトし、web_onlyコンテナを再構築して停止&開始しましたが、上記のエラーメッセージは残ったままです。
これにより、this.class.createの管理ページにアクセスすると「関数ではありません」という別のエラーメッセージが表示されますが、これはおそらく、このテストのために基盤となるdocker_managerプラグインが無効になっているため、予想される動作かもしれません。
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
at loader.js:247:1
at h (loader.js:258:1)
at u.findDeps (loader.js:168:1)
at h (loader.js:262:1)
at requireModule (loader.js:24:1)
at f.get (composer.js:874:1)
at push.98673._extractDefaultExport (composer.js:874:1)
at push.98673.resolveOther (composer.js:874:1)
at push.98673.resolve (composer.js:874:1)
at n.i [as getRoute] (upload-debugging.js:25:1)
at p._getQPMeta (upload-debugging.js:25:1)
index.js:78 Uncaught TypeError: this.class.create is not a function
at n.i [as getRoute] (upload-debugging.js:25:1)
at p._getQPMeta (upload-debugging.js:25:1)
繰り返しになりますが、no_pluginsでセーフモードを使用すると、一時的に問題は回避されます。
2 コンテナの最小ダウンタイム更新のコマンドを記憶から実行したのですが、どうやら私の記憶は当てになりませんでした!![]()
ブートストラップ後に新しいコンテナを起動する前に、適切なコマンドを使用してコンテナを破棄してから起動したところ、バージョンが更新され、管理インターフェイスが期待どおりに動作していることがわかりました。
データコンテナをアップグレードしましたか?行うべきですが、まずPostgreSQL 15 updateを参照してください。または、読むのが本当に嫌いな場合は、./laumcher rebuild dataを2回実行するだけで大丈夫なはずです。その後、Webコンテナを破棄して開始する必要があります(そうしないと、破棄した古いデータコンテナを探し続けることになります)。
まだですが、気にかけてくれてありがとうございます!
すでに新しいパワフルなサーバーのセットアップを検討していたので、Discourse 3.5 + PG13 からバックアップし、別のホストの Discourse 3.5 + PG15 にリストアできるかどうかを調べていました。
長時間のダウンタイムは避けたいので、過去には一時的にコミュニティを読み取り専用にし、サーバーインスタンス間でバックアップ/リストアを行ったことがあり、実質的にダウンタイムはゼロでした(もちろん、読み取り専用期間を除く)。そのため、PG バージョン間で機能するかどうかを調べてテストしてみようと思いました。
それ以外の場合は、サーバー移行の前に PG15 のアップグレードを済ませるという覚悟を決めます。![]()
機能します。おそらくOSをアップグレードする時期でもあります。新しいサーバーを起動し、バックアップを復元してください。
全く同じ問題が発生しました。ご協力ありがとうございます。私のウェブマスターであるベンジャミンが確認します。
ミュリエル
これが私に起こったことです。新しいサーバーを立ち上げてバックアップから復元するのが唯一の選択肢でした。
彼は要点を押さえています。そして、デバッグに時間を無駄にしないでください。このアドバイスですぐに解決します。
結局、バックアップと復元を行い、期待どおりに動作しました。
参考までに、他の誰かが同様の問題に遭遇した場合に備えて…
最初に少し問題が発生しました。復元プロセスが内部的に uploads:migrate_to_s3 を呼び出すようで、そこでハングアップしていました。
2025-02-26 00:24:16] Migrating the database...
[2025-02-26 00:24:24]
[2025-02-26 00:24:24] Reconnecting to the database...
[2025-02-26 00:24:24] Reloading site settings...
[2025-02-26 00:24:24] Disabling outgoing emails for non-staff users...
[2025-02-26 00:24:24] Disabling readonly mode...
[2025-02-26 00:24:24] Clearing category cache...
[2025-02-26 00:24:24] Reloading translations...
[2025-02-26 00:24:24] Remapping uploads...
[2025-02-26 00:24:24] Restoring uploads, this may take a while...
[2025-02-26 00:25:09] EXCEPTION: 12 of 12208 uploads are not migrated to S3. S3 migration failed for db 'default'.
[2025-02-26 00:25:09] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:73:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:383:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:354:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:167:in `restore_uploads'
/var/www/discourse/lib/backup_restore/restorer.rb:71:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:20:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:33:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2025-02-26 00:25:09] Trying to rollback...
[2025-02-26 00:25:09] Rolling back...
[2025-02-26 00:25:10] Cleaning stuff up...
データコンテナでいくつかの SQL クエリを実行して、何が起こっているのかを把握しようとしました。
./launcher enter data
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%s3%';
これは Discourse の標準的な組み込みアイテムを返しただけだったので、逆に試してみました。
SELECT url from uploads where url LIKE '%s3%' limit 10;
これは次のような形式の多くのマッチを返しました。
//{my-bucket-name}.s3.dualstack.us-east-2.amazonaws.com/original/2X/5/{image-id}.jpeg
次に、その s3.dualstack ホストに一致しないすべてのアイテムを取得するクエリを試したところ、12 個の古いエントリがわずかに異なる形式(以前の復元ログの失敗から失敗した数と一致)を使用していることがわかりました。
//{my-bucket-name}.s3-us-east-2.amazonaws.com/{file-path}.jpeg
実際のバケットでそれらのファイルの存在を確認したところ、存在しなかったため、次のようなもので削除しました。
DELETE FROM uploads where url LIKE '%{my-bucket-name}.s3-us-east-2.amazonaws.com%';
その後、バックアップと復元は期待どおりに動作しました!
PS. バックアップを復元した後、メールを再度有効にすることを忘れないでください!
/admin/site_settings/category/all_results?filter=disable_email
2件の投稿が新しいトピックに分割されました: 10年前のサイトの更新で問題が発生しています
