chaus
(Jason)
24
遇到了同样的问题……在 Ubuntu 20.04 上使用 DO Droplet。尝试先从 Discourse 内部升级 Docker,但一直出现错误代码 137。然后我尝试从命令行重建 Discourse,它卡在了 The database is ready to accept connections。Ctrl+C 没有反应,所以我关闭了 SSH 并打开了一个新的,然后重新启动了 Discourse,它仍然可以工作但没有更新。我重启了 Droplet 并再次尝试从 Discourse 升级 Docker,这次成功了!然后我再次尝试重建 Discourse,但它仍然卡在同一个地方。再次关闭 SSH 并打开并重新启动 Discourse,但现在我看到了 Oops 屏幕!所以现在我的 Discourse 网站无法访问,我以前唯一能从 Oops 屏幕恢复的方法就是重建应用程序,但我现在做不到!
所以我现在很迷茫,因为我的 Discourse 和 Droplet 经验非常有限,我不知道现在还能做什么。docker_manager 是我 app.yml 中唯一使用的插件,所以我只能假设错误是由于 Docker 是一个较新版本,与我的 Discourse 版本不兼容?我不知道。我最后一次更新 Discourse 是在一月份,所以它也不是那么过时……
所以我的网站将一直处于关闭状态,直到这个问题被解决……除非我启动一个新的 Droplet 并重新设置所有东西,然后恢复我之前备份的 Discourse?这是我目前唯一的选择吗?
pfaffman
(Jay Pfaffman)
25
错误 137 是内存不足。我会尝试增加更多交换空间。如果您只有 1GB 内存,我可能会将其调整为 2GB,并可能还有 3 或 4GB 的交换空间。
您可以尝试
./launcher start app
但我怀疑数据库已经迁移得太远,无法用于旧容器。
如果您遇到困难并需要付费支持,请访问 Contact Us - Literate Computing
编辑:但这是我会做的:
你好,这里也有同样的错误。目前可以通过在app.yml中强制版本参数为v3.3.0来解决。架构AMD64,Ubuntu 18.04。奇怪的是,小版本失败了,上周更新到v3.3.0没有问题 
1 个赞
tgxworld
(Alan Tan)
27
如果有人遇到此问题并且愿意让我访问您的服务器,请给我发私信,以便我可以在出现问题的服务器上调试该问题。我已经尝试了多种方法,但无法重现此问题,这使得推送修复程序更加困难。
5 个赞
对于那些因 Discourse 宕机而遇到此问题的人,我发现您可以通过重启虚拟机然后运行 ./launcher start app 来至少恢复论坛的旧版本。在尝试重建而未重启实例/虚拟机后,此命令将无法正常工作。
我应该能在周一在受影响的虚拟机上升级 Ubuntu 版本,届时会向大家通报结果。
1 个赞
sallypf
(Sally)
31
当卡住时,Ctrl+c 不起作用,必须重新启动系统。
sallypf
(Sally)
32
此命令也无效。
**/var/discourse**# ./launcher start app
检测到 x86_64 架构。
警告:containers/app.yml 文件是全局可读的。您可以通过运行以下命令来保护此文件:chmod o-rwx containers/app.yml
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=techoforum.com -e DISCOURSE_DEVELOPER_EMAILS=techoforumd@gmail.com -e DISCOURSE_SMTP_ADDRESS=smtp.sendgrid.net -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=apikey -e DISCOURSE_SMTP_PASSWORD=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 -e DISCOURSE_SMTP_DOMAIN=gmail.com -e DISCOURSE_NOTIFICATION_EMAIL=techoforumd@gmail.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h discourseonubuntu2004-s-1vcpu-1gb-sfo3-01-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f8:99:7d:c3:d6 local_discourse/app /sbin/boot
在本地找不到镜像 'local_discourse/app'
docker:守护进程的错误响应:拉取访问被拒绝,镜像 'local_discourse/app' 不存在或可能需要 'docker login':拒绝:请求访问该资源被拒绝。
请参阅 'docker run --help'。
sallypf
(Sally)
33
我在另一个液滴上还有另一个论坛,更新时没有出现任何问题。奇怪的是,为什么在相同的服务器配置下,一个液滴有问题而另一个没有?
pfaffman
(Jay Pfaffman)
34
这听起来像是内存(RAM)问题。您有多少内存和交换空间?我建议添加一两个 GB 的交换空间(如果您只有 1GB 内存,也可以考虑添加内存)
这些系统有多少内存和交换空间?输出是什么?
free -h
内存问题可以解释为什么 @tgxworld 无法重现它。
我相当确定问题出在内存/交换空间上。
tgxworld
(Alan Tan)
35
顺便说一句,对于遇到此问题的任何人,您可以通过将 base_image: discourse/base:2.0.20240708-0023 添加到 containers/app.yml 文件的顶部来暂时解决此问题。
5 个赞
不确定这是否是我的内存问题,因为受影响的虚拟机分配了 125 GiB 内存,可用内存为 78 GB。
total used free shared buff/cache available
Mem: 125G 14G 940M 31G 110G 78G
Swap: 0B 0B 0B
在没有此问题的情况下成功升级的具有相同操作系统的开发服务器只有 16 GiB RAM。
1 个赞
这可能是数据库大小的问题吗?
我们生产服务器上的数据库相当大,但开发环境的数据库却很小。这是已成功升级的虚拟机和受影响的虚拟机(就我而言)之间唯一的真正区别。
这是唯一对我有效的方法。感谢分享!!我的客户也感谢您 
希望我们能尽快得到妥善的修复。
1 个赞
sallypf
(Sally)
42
您好,
我刚刚将 Droplet 的内存加倍并增加了磁盘大小。我仍然遇到同样的问题。
还有什么可以尝试的吗?
# free -h
total used free shared buff/cache available
Mem: 1.9Gi 289Mi 83Mi 11Mi 1.6Gi 1.5Gi
Swap: 2.0Gi 3.0Mi 2.0Gi
# df -h
Filesystem Size Used Avail Use% Mounted on
udev 941M 0 941M 0% /dev
tmpfs 198M 1.1M 197M 1% /run
/dev/vda1 34G 14G 21G 39% /
tmpfs 986M 0 986M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 986M 0 986M 0% /sys/fs/cgroup
/dev/vda15 105M 7.4M 97M 8% /boot/efi
/dev/loop1 56M 56M 0 100% /snap/core18/2829
/dev/loop2 56M 56M 0 100% /snap/core18/2823
/dev/loop3 92M 92M 0 100% /snap/lxd/29619
/dev/loop0 64M 64M 0 100% /snap/core20/2264
/dev/loop4 64M 64M 0 100% /snap/core20/2318
/dev/loop5 39M 39M 0 100% /snap/snapd/21465
/dev/loop6 92M 92M 0 100% /snap/lxd/24061
/dev/loop7 39M 39M 0 100% /snap/snapd/21759
tmpfs 198M 0 198M 0% /run/user/0
overlay 34G 14G 21G 39% /var/lib/docker/overlay2/3c7ebf42647de2b5df34cba2b047079fd3454ea7fe9b04c7b70f227df1e7eafe/merged
1 个赞
sallypf
(Sally)
43
我的天!我为什么之前没有看到这个解决方案。它也对我有用。
那么,未来的解决方案是什么?我们将来还需要继续指定这个基础镜像,还是更改它以获取更新的镜像?