Discourse 在 Admin UI 中更新失败 - 无论如何

在管理员部分使用 UI 更新程序进行更新时,它总是失败。自从我一年前安装 Discourse 以来,它一直失败。我可以轻松地通过 SSH 进入我的服务器进行手动更新,但一个功能不正常运行令人沮丧。

由于 Discourse 是通过 Docker 运行的,而我对 Docker 并不十分了解,我想知道是否有人遇到过类似的问题,以及我该如何解决。

简而言之:UI 更新程序总是失败,命令行可以一次性成功,我想修复它,这样我就不必(经常)SSH 进入服务器。

谢谢!

1 个赞

您好,情况也是如此,几个月来一直如此。

如果您通过 SSH 连接到服务器,free -h 会返回什么?

我意识到在进行了一些挖掘之后,可能是我使用了最低限度的内存推荐,但这是用于私有安装,用户少于 50 人,所以我真的不需要为我的用例超过最低要求。

image

我不能有超过3个并发用户,但我需要更多。我认为您需要升级您的VPS。

我以前可以用 2G 内存 + 2G 交换空间进行更新,但我想那是在 ember 之前,ember 的要求非常高。如果您有足够的磁盘空间将交换空间增加到 4G,那可能会奏效。或者,暂时谨慎地迁移到具有更多内存的实例,进行更新,然后再迁移回来。

无论您做什么,请先备份并下载。

1 个赞

我将查看交换选项,看看是否有帮助。我有 2GB 内存和 80GB 磁盘。

不幸的是,我的提供商不支持自动更改系统资源,但我也想支付不超过 5 美元。

感谢您的帮助。

我以前有 2GB 内存和 40GB 磁盘,依靠 .\discourse-setup 配置交换空间,Web UI 更新很慢

1 个赞

这个 Ionos USA 托管可能值得一看

是的,我在下一级,一年后是每月8美元。可惜。

1 个赞

我知道 Contabo 提供价格合理的 VPS。


你说的是 5 以下…

1 个赞

哇,价格不错。我来看看。谢谢!

2 个赞

美国市场ContaboIONOS 都允许入站端口 25,这对于 mail-receiver 配置至关重要 — 因此在这方面没有功能限制。

真正的区别在于可靠性和支持声誉

  • ContaboTrustpilot 4.2/5,约 6,700 条评论)提供极具竞争力的价格和高规格配置,但美国用户经常报告高延迟响应较慢的支持性能不稳定,尤其是在负载下。Contabo 的美国数据中心确实存在,但它们的响应速度并不总是如预期般快。

  • IONOSTrustpilot 4.5/5,约 31,000 条评论)在美国的表现比许多人想象的要好。它拥有更好的支持声誉和更可靠的基础设施,一星评价较少(约 10%,而 Contabo 为 16%)。与 Contabo 相比,用户普遍报告了更好的正常运行时间实时支持账户管理

结论(美国):
如果您在美国,并且需要稳定性、快速支持以及在生产工作负载方面低风险的选择,那么IONOS 是更安全的选择。Contabo 对于开发/测试环境或对成本敏感的部署仍然值得考虑,但要准备好在延迟和支持质量方面做出权衡。

3 个赞

我的也开始这样了,四年多以来一直运行正常,现在却失败了。虽然有时它声称失败了,但当我刷新时,一切都是最新的,而且没有需要再次更新的东西。但它几乎总是以以下内容结束:

ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL 命令被 SIGKILL(强制终止)杀死:ember build -prod /var/www/discourse/script/assemble_ember_build.rb:103:in `system': 命令失败,退出代码为 1:pnpm (RuntimeError) from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>' Docker Manager: 升级失败

在几乎所有情况下,查看输出的前 50 到 200 行将非常有帮助。可惜脚本没有建议这样做。

1 个赞

我当时就在想——是不是和代码本身的问题有关,而不是我的服务器硬件问题。

我想我的下一个选择就是写一个自己的插件,用一个脚本来手动更新我自己。

很高兴其他人也有同样的问题,所以不是只有我(我知道这很糟糕)。也许一些积极开发 Discourse 的人可以关注一下。我也希望有更好的调试信息,而不是仅仅“失败”。

Ed,我会看看能不能帮你拿到。然后马上发给你。

我不是开发者,也不是服务器方面的专家。我选择 Digital Ocean 是因为它在官方安装说明中被提及,而且多年来我一直看到这个名字被反复提及。

目前我使用的是倒数第二低的套餐,每月 6 美元,服务器似乎比 Contabo 或 IONOS 提供的服务器“慢”得多。由于良好的 Discourse 性能至少需要 2GB 内存,我将不得不升级到 12 美元的套餐。而 Contabo 每月 4.95 美元套餐,我将获得 8GB 内存……这在价格和内存方面都有“巨大”的差异 ;),更不用说磁盘空间等了。

所以,我想问问您和其他有经验的用户,我是否应该将我的 Discourse 迁移到 Contabo,而不是继续使用 Digital Ocean?尽管我还在建设整个社区,但到目前为止 DO 还可以,除了在 Web 上更新 Discourse 时出现问题,即使有 4GB 的交换文件(因为我的磁盘空间只有 25GB),但我不想迁移所有内容然后才开始注意到其他问题。

我找到了这个页面,但不确定这些测试的可靠性有多大,以及它们是否足以让我做出改变?

非常感谢任何反馈!
谢谢!:raising_hands:

2 个赞

这完全破坏了 Digital Ocean 每月 6 美元、仅 1GB 内存的配置……

您会推荐切换吗?

********************************************************
*** 请耐心等待,后续步骤可能需要一些时间 ***
********************************************************
正在重启 Unicorn,以释放内存
正在重启 unicorn pid: 1580
等待 Unicorn 重新加载。
等待 Unicorn 重新加载..
等待 Unicorn 重新加载...
等待 Unicorn 重新加载....
等待 Unicorn 重新加载.....
等待 Unicorn 重新加载......
等待 Unicorn 重新加载.......
等待 Unicorn 重新加载........
等待 Unicorn 重新加载.........
等待 Unicorn 重新加载..........
等待 Unicorn 重新加载...........
等待 Unicorn 重新加载............
等待 Unicorn 重新加载.............
等待 Unicorn 重新加载..............
正在停止 1 个 Unicorn 工作进程,以释放内存
正在停止作业队列以回收内存,主进程 pid 为 1585
$ cd /var/www/discourse && git fetch --tags --prune-tags --prune --force
$ cd /var/www/discourse && git reset --hard HEAD@{upstream}
HEAD 现在位于 20ff23ed0 DEV: 为禁用的新主题按钮删除冗余翻译 (#33929)
$ bundle install --retry 3 --jobs 4
Bundle 完成!160 个 Gemfile 依赖项,现在已安装 207 个 gem。
组 'test' 和 'development' 中的 Gem 未安装。
Bundled gem 已安装到 `./vendor/bundle`
您直接依赖的 3 个已安装 gem 正在寻找资金支持。
  运行 `bundle fund` 获取详细信息
$ if [ -f yarn.lock ]; then yarn install; else CI=1 pnpm install; fi
范围:所有 16 个工作区项目
锁定文件是最新的,跳过解析步骤
已是最新

Done in 2.9s using pnpm v9.15.9
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-custom-wizard 已是最新兼容版本
docker_manager 已是最新兼容版本
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
多站点迁移器正在使用 1 个线程运行

正在迁移 default
正在初始化 default
*** 正在打包资源。这需要一些时间 *** 
$ bundle exec rake themes:update assets:precompile
正在使用并发 10 更新主题
[db:default] 'Air Theme' -  正在检查...
[db:default] 'Air Theme' -  已是最新
[db:default] 'Modern Category + Group Boxes' -  正在检查...
[db:default] 'Modern Category + Group Boxes' -  已是最新
[db:default] 'Clickable Topic' -  正在检查...
[db:default] 'Clickable Topic' -  已是最新
[db:default] 'Search Banner' -  正在检查...
Node.js heap_size_limit 小于 2048MB。正在设置 --max-old-space-size=2048 和 CHEAP_SOURCE_MAPS=1
现有构建不可重用。
- Existing: {"ember_env"=>"production", "core_tree_hash"=>"cd74e4ac33647244c041061633d6ca67f9166e5c"}
- Current: {"ember_env"=>"production", "core_tree_hash"=>"7ac67590cc51e22690a2711b593892cd1d266781"}
正在运行完整核心构建...
正在构建
Environment: production
Embroider 的 'staticAddonTrees' 设置将在下一个版本中默认为 true,并且无法关闭。为准备此更改,您应该在 Embroider 配置中设置 'staticAddonTrees: true'。
Embroider 的 'staticAddonTestSupportTrees' 设置将在下一个版本中默认为 true,并且无法关闭。为准备此更改,您应该在 Embroider 配置中设置 'staticAddonTestSupportTrees: true'。
building...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] 注意:代码生成器已对 /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js 的样式进行了优化,因为它超过了 500KB 的最大值。
[BABEL] 注意:代码生成器已对 /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js 的样式进行了优化,因为它超过了 500KB 的最大值。
...[Babel: @glimmer/component > applyPatches]
...[Babel: @ember/test-waiters > applyPatches]
...[Babel: ember-this-fallback > applyPatches]
...[Babel: ember-cache-primitive-polyfill > applyPatches]
...[Babel: select-kit > applyPatches]
...[@embroider/compat/app]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
undefined
 ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL  命令被 SIGKILL (强制终止) 杀死:ember build -prod
/var/www/discourse/script/assemble_ember_build.rb:103:in `system': Command failed with exit 1: pnpm (RuntimeError)
	from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>'
Docker Manager: 升级失败
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:211:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:112:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `block in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2/lib/active_support/execution_wrapper.rb:91:in `wrap'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:70:in `conditional_executor'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:178:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor.rb:538:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:73:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:65:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:143:in `with_argv'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:63:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands.rb:18:in `<main>'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.18.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
正在启动 1 个最初已停止的 Unicorn 工作进程

不客气。我今天复现了这个问题。

1 个赞