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 を更新したのは 1 月なので、それほど古くはありません…
そのため、この問題が解決されるまで、私のサイトはダウンしています… 新しい Droplet を起動し、すべてを再設定して Discourse バックアップを復元する以外に方法はありませんか？現時点ではそれが唯一の選択肢ですか？ 
pfaffman
(Jay Pfaffman)
25
エラー137はメモリ不足です。スワップを増やすことをお勧めします。RAMが1GBしかない場合は、2GBにリサイズし、スワップも3GBまたは4GBにするのが良いかもしれません。
./launcher start app
を試すこともできますが、データベースが古いコンテナには移行しすぎている可能性があります。
行き詰まって有料サポートが必要な場合は、Contact Us - Literate Computing を参照してください。
編集：しかし、私がやるならこうします。
こんにちは、ここでも同じエラーが発生しています。現在のところ、回避策は app.yml のバージョン パラメータを v3.3.0 に強制することです。Arch AMD64、Ubuntu 18.04。マイナーバージョンが失敗したのは奇妙です。先週は v3.3.0 へのアップデートは問題なく完了しました 
「いいね！」 1
tgxworld
(Alan Tan)
27
この問題に遭遇し、サーバーへのアクセスを提供していただける方は、問題が発生しているサーバーでデバッグできるように、プライベートメッセージ（PM）でご連絡ください。複数の方法を試しましたが、この問題を再現できず、修正の推進が困難になっています。
「いいね！」 5
chaus
(Jason)
28
プロフィールにあなたにプライベートメッセージを送る方法が見つかりません…
Moin
29
メッセージを送信するには、信頼レベル1に到達する必要があります。
プロフィールにある統計情報を見ると、すでにかなり近いようです。
「いいね！」 2
Discourseがダウンしているこの問題で困っている方のために、VMを再起動してから./launcher start appを実行することで、少なくともフォーラムの古いバージョンを起動できることがわかりました。このコマンドは、インスタンス/VMを再起動せずに再構築を試みた後では機能しません。
影響を受けているVMのUbuntuのバージョンを月曜日に更新できるはずなので、結果については皆さんに随時報告します。
「いいね！」 1
sallypf
(Sally)
31
Ctrl+c がフリーズしたときに機能せず、システムを再起動する必要があります。
sallypf
(Sally)
32
このコマンドも何も実行されません。
**/var/discourse**# ./launcher start app
x86_64 arch detected.
WARNING: containers/app.yml file is world-readable. You can secure this file by running: 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
Unable to find image 'local_discourse/app:latest' locally
docker: Error response from daemon: pull access denied for local_discourse/app, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
See 'docker run --help'.
sallypf
(Sally)
33
別のドロップレットで別のフォーラムを運用していますが、そちらはアップデートに問題はありません。同じサーバー構成なのに、なぜ一方のドロップレットで問題が発生し、もう一方では発生しないのか、不思議です。
pfaffman
(Jay Pfaffman)
34
RAM の問題のようですね。RAM とスワップはどれくらいありますか？スワップ領域を 1 GB または 2 GB 追加することをお勧めします (RAM が 1 GB しかない場合は、RAM も追加するかもしれません)。
これらのシステムには、RAM とスワップはどれくらいありますか？
free -h
の出力はどうなりますか？
RAM があれば、@tgxworld が再現できなかった理由が説明できます。
RAM/スワップが問題であると確信しています。
tgxworld
(Alan Tan)
35
ちなみに、この問題が発生した場合は、一時的な回避策として containers/app.yml ファイルの先頭に base_image: discourse/base:2.0.20240708-0023 を追加できます。
「いいね！」 5
私のケースではRAMの問題ではないと思われます。影響を受けたVMには125 GiBが割り当てられ、78 GBが利用可能です。
total used free shared buff/cache available
Mem: 125G 14G 940M 31G 110G 78G
Swap: 0B 0B 0B
この問題なく正常にアップグレードされた、同じOSの開発サーバーは16 GiBのRAMしかありません。
「いいね！」 1
データベースサイズの可能性はありますか？
本番サーバーのデータベースはかなり大きいですが、開発環境は非常に小さいです。それが、正常にアップグレードされたVMと影響を受けたVM（私の場合は）との唯一の本当の違いです。
これが私にとって唯一うまくいったことです。共有していただきありがとうございます!! 私のお客様も感謝しています 
すぐに適切な修正が得られることを願っています。
「いいね！」 1
sallypf
(Sally)
42
こんにちは。
DropletのRAMを倍増し、ディスクサイズを増やしてアップグレードしましたが、まだ同じ問題が発生しています。
他に試せることはありますか？
# 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
OMG！なぜこの解決策を先に読まなかったのだろう。私もこれでうまくいきました。
では、今後の解決策はどうなるのでしょうか？今後もこのベースイメージを指定し続ける必要があるのでしょうか、それとも更新されたイメージを取得するために変更する必要があるのでしょうか？
