コアダンプと無効な命令は、CPUやメモリなどの低レベルで何かが間違っていることを示しています。
私はハードウェアの専門家ではありませんが、このCPUは12年前に市場に出たもので、古すぎるのではないかと疑っています(つまり、新しいCPUを前提としたコンパイル済みコードを実行しようとしている可能性があります)。
コアダンプと無効な命令は、CPUやメモリなどの低レベルで何かが間違っていることを示しています。
私はハードウェアの専門家ではありませんが、このCPUは12年前に市場に出たもので、古すぎるのではないかと疑っています(つまり、新しいCPUを前提としたコンパイル済みコードを実行しようとしている可能性があります)。
これも検討しましたが、過去3年間問題なく動作していたことを考えると、スタック内で突然新しい命令を必要とするようになったものは何でしょうか?(また、どの命令でしょうか?)
FEATURE: Add support for clear_every parameter in Redis backend (#309) · discourse/message_bus@1baa1ea · GitHub はRedis内で異なる動作を引き起こすのでしょうか?![]()
さらに、先週金曜日にはメジャーバージョンアップグレードが問題なく実行され、週末を通して問題なく稼働していました。日曜日には正常なアップデートも実行しました。もしCPUが原因であれば、それは理解できますが、メジャーバージョンアップグレードでも同様のエラーが発生していたはずです。
しかし、月曜日以降に変更があったのかもしれません…
それは十分にあり得ます。メッセージバスのコードのJSON解析ルーチンでクラッシュしていますが、あなたが言及した変更は4ヶ月以上前のものです。
-- Cレベルのバックトレース情報 -------------------------------------------
/usr/local/lib/libruby.so.2.7(rb_vm_bugreport+0x50a) [0x7f30fc64839a] vm_dump.c:755
[0x7f30fc4b9b47]
/usr/local/lib/libruby.so.2.7(sigill+0x3b) [0x7f30fc5c4f0b] signal.c:962
/lib/x86_64-linux-gnu/libc.so.6(0x7f30fc283d60) [0x7f30fc283d60]
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/oj-3.13.15/lib/oj/oj.so(oj_parse2+0x4f9) [0x7f30f3a68339] /usr/lib/gcc/x86_64-linux-gnu/10/include/smmintrin.h:649
I, [2022-07-05T10:03:30.513303 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-4.2.0/lib/message_bus/codec/json.rb:11: [BUG] Illegal instruction at 0x00007f30f3a68339
ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux]
-- コントロールフレーム情報 ----------------------------------------------
c:0030 p:---- s:0162 e:000161 CFUNC :parse
c:0029 p:0013 s:0157 e:000156 METHOD /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-4.2.0/lib/message_bus/codec/json.rb:11
c:0028 p:0037 s:0152 e:000151 METHOD /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-4.2.0/lib/message_bus.rb:648
c:0027 p:0020 s:0144 e:000143 BLOCK /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-4.2.0/lib/message_bus.rb:766
c:0026 p:0082 s:0135 e:000134 BLOCK /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-4.2.0/lib/message_bus/backends/redis.rb:330
c:0025 p:0024 s:0130 e:000129 BLOCK /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.5.1/lib/redis/subscribe.rb:46
c:0024 p:0034 s:0124 e:000123 BLOCK /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.5.1/lib/redis/client.rb:183 [FINISH]
ええ…だから、それはすでに日曜日に存在しているはずでした。![]()
ログを確認したところ、Redisを起動しようとした際に、すでに別のRedisインスタンスが実行されているようです。
これが原因でしょうか?
102:C 05 Jul 2022 09:53:34.597 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
102:C 05 Jul 2022 09:53:34.597 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=102, just started
102:C 05 Jul 2022 09:53:34.597 # Configuration loaded
102:M 05 Jul 2022 09:53:34.598 * monotonic clock: POSIX clock_gettime
102:M 05 Jul 2022 09:53:34.599 * Running mode=standalone, port=6379.
102:M 05 Jul 2022 09:53:34.599 # Server initialized
102:M 05 Jul 2022 09:53:34.599 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
102:M 05 Jul 2022 09:53:34.599 * Loading RDB produced by version 6.2.6
102:M 05 Jul 2022 09:53:34.599 * RDB age 1972 seconds
102:M 05 Jul 2022 09:53:34.599 * RDB memory usage when created 60.60 Mb
102:M 05 Jul 2022 09:53:34.949 # Done loading RDB, keys loaded: 8005, keys expired: 9.
102:M 05 Jul 2022 09:53:34.950 * DB loaded from disk: 0.351 seconds
102:M 05 Jul 2022 09:53:34.950 * Ready to accept connections
129:C 05 Jul 2022 09:53:45.056 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
129:C 05 Jul 2022 09:53:45.056 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=129, just started
129:C 05 Jul 2022 09:53:45.056 # Configuration loaded
129:M 05 Jul 2022 09:53:45.057 * monotonic clock: POSIX clock_gettime
129:M 05 Jul 2022 09:53:45.057 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
129:M 05 Jul 2022 09:53:45.057 # Failed listening on port 6379 (TCP), aborting.
102:signal-handler (1657015415) Received SIGTERM scheduling shutdown...
102:M 05 Jul 2022 10:03:35.245 # User requested shutdown...
102:M 05 Jul 2022 10:03:35.245 * Saving the final RDB snapshot before exiting.
102:M 05 Jul 2022 10:03:39.882 * DB saved on disk
102:M 05 Jul 2022 10:03:39.882 # Redis is now ready to exit, bye bye...
これは launcher rebuild app ではよくあることで、(少なくとも私の知る限りでは) 何にも影響しません。
コードパスは、特定のデータが存在するかしないかによってもトリガーされる可能性があります。おそらく、問題のコードは存在していましたが、実行されていなかったのでしょう。
最新のコミットセットに対して準二分探索を試してみて、特定の最近の変更に絞り込めるかどうか見てみます。これには「ある程度の時間」がかかります… ![]()
編集:
さて、不正な命令を持つ最初の壊れたコミットは Build(deps): Bump oj from 3.13.14 to 3.13.15 (#17309) · discourse/discourse@4c69619 · GitHub で、これは Fix NaN object dump issue · ohler55/oj@f0122cf · GitHub にリンクされています。
以前のコミットもビルドに失敗しますが、異なる問題が発生します(これも一時的な問題のように見えます…):
I, [2022-07-05T12:14:35.377926 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
102:M 05 Jul 2022 12:14:44.308 * 100 changes in 300 seconds. Saving...
102:M 05 Jul 2022 12:14:44.312 * Background saving started by pid 709
709:C 05 Jul 2022 12:14:45.166 * DB saved on disk
709:C 05 Jul 2022 12:14:45.169 * RDB: 1 MB of memory used by copy-on-write
102:M 05 Jul 2022 12:14:45.217 * Background saving terminated with success
I, [2022-07-05T12:14:46.192386 #1] INFO -- :
I, [2022-07-05T12:14:46.193317 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Missing yarn packages:
Package: ember-cli-deprecation-workflow
* Specified: ^2.1.0
* Installed: (not installed)
Run `yarn` to install missing dependencies.
Stack Trace and Error Report: /tmp/error.dump.ccfa3d8342a442ee6860db37ce7c7330.log
An error occurred in the constructor for ember-cli-dependency-checker at /var/www/discourse/app/assets/javascripts/node_modules/ember-cli-dependency-checker
error Command failed with exit code 1.
見つけましたね。確かに oj gem でクラッシュしています。
バージョン 3.13.15 には、パフォーマンスのために SSE 4.2 命令の使用に切り替えたこのコミットも含まれています。そして、それらはAMD Opteron 41xx プロセッサではサポートされていません。
したがって、元に戻ります。
私の意見では、gem の著者がこれをコンパイル時の決定にしたのは残念です。
素晴らしい。ojの変更ログには記載されていない追加の変更です… ![]()
したがって、gemがインストール中にネイティブコンパイルを行わない場合(OJ_USE_SSE4_2で動作するように促すことができる可能性があります)、サーバーの移動が必要になるようです… ![]()
編集:gemは事前コンパイルされたオブジェクトを配布していないため、これは機能するはずです。次の質問は、サポートされていないシステムでSSE4.2でコンパイルされる理由です。
現在のベースイメージには3.13.14が含まれているため、システム上でコンパイルされています。
コミットのベンチマークスクリプトを使用して、エラーを再現できますか?
○ → docker run --rm -it -u discourse discourse/base:2.0.20220621-0049 bash
discourse@313d7af3be39:/$ cd
discourse@313d7af3be39:~$ gem install --user pry benchmark-ips oj
…
Successfully installed oj-3.13.15
5 gems installed
discourse@313d7af3be39:~$ /home/discourse/.local/share/gem/ruby/2.7.0/bin/pry
[1] pry(main)> require 'benchmark/ips'
require 'oj'
def json(string)
"\"#{string}\""
end
Benchmark.ips do |x|
x.warmup = 5
x.time = 20
json_0 = json('a' * 0)
json_64 = json('a' * 64)
json_128 = json('a' * 128)
x.report('Oj.load [0]') { Oj.load(json_0) }
x.report('Oj.load [64]') { Oj.load(json_64) }
x.report('Oj.load [128]') { Oj.load(json_128) }
end;
問題のある命令でコンパイルされたかどうかは、次でも確認できます。
discourse@313d7af3be39:~$ objdump -d /home/discourse/.local/share/gem/ruby/2.7.0/gems/oj-3.13.15/lib/oj/oj.so | grep -C3 pcmpestri
2e32b: 0f 82 b5 03 00 00 jb 2e6e6 <oj_parse2+0x8a6>
2e331: 66 0f 6f 05 77 d6 01 movdqa 0x1d677(%rip),%xmm0 # 4b9b0 <exp_plus+0x330>
2e338: 00
2e339: 66 0f 3a 61 07 00 pcmpestri $0x0,(%rdi),%xmm0
2e33f: 83 f9 10 cmp $0x10,%ecx
2e342: 74 dc je 2e320 <oj_parse2+0x4e0>
2e344: 48 63 c9 movslq %ecx,%rcx
もしそうであれば、これはoj gemのプロジェクトに報告すべきことでしょう。
もう少し詳しく調べたいのですが、1) ダウンタイムをさらに避けたい(少なくともしばらくは。上記にはダウンタイムは含まれていませんが、他のことを試したくなるかもしれません)こと、そして 2) 以下の場合です。
が 3.13.15 になり、Discourse のベースイメージが同じ最小 CPU マイクロアーキテクチャ要件を継承した場合、現在のサーバーは持続可能ではなくなります(gem を個別に(再)インストールするなど、回避策がある場合を除き、例えばコード前のフックの一部としてですが、それはほとんどの人にとって少し面倒なことだと思います)。
また、そもそもハードウェアサポートの合理的なカットオフ日は何であるべきかという疑問も生じます。32 ビット CPU サポートを期待するのは合理的ではありません。したがって、最新ソフトウェアの合理的な「新しい最小値」は SSE4.2 かもしれません。
確かに、すでに内部で提起しました。
![]()
こんにちは!
ご確認いただきありがとうございます。私も2011年末のIntel Atom N2800で同じ問題が発生しています。
この問題の回避策があると思われますか、それとも現時点では新しいハードウェアに移行するしかないのでしょうか?
よろしくお願いします。
今日のアップデートを促されて、フォーラムが完全に停止してしまいました。CPUの廃止に関する警告は一切見ていませんでしたし、このような事態が突然起こるというのは…最悪です。利用可能なサーバーは、一貫性を保つためにすべて同じ構成であり、すべて同じCPUを使用しています。
AMD Athlon™ II X2 B22 Processor
このような経済状況で、時間があったとしても、すぐに新しいサーバーを購入して設定するのは現実的ではありません。
この状況がよりよく理解されるまで、このアップデートを元に戻す方法はありますか?フォーラムがダウンしているため、ユーザーに連絡することさえできません。よろしくお願いします。
Dockerデプロイメントメソッドを使用している場合、古いコンテナを再起動できる場合があります(例:docker imagesおよび/またはdocker ps -aを確認してください)。
また、app.ymlを編集してバージョンを変更前のコミットに設定し、再構築することで、Discourseインスタンスのビルドに使用されたコミットを上書きすることもできます。
params:
version: adb7fa5e2fc51308efc9fc4ee57ecb1c15a85cfa
その後アップデートするとDiscourseは再び壊れますが、それ以降にリリースされたセキュリティアップデート(ただし、ほとんどのインスタンスでは悪用の可能性はかなり限定的であるようです)を考慮すると、これは理想的ではありません。
1つの選択肢(まだ試していませんが)は、oj gemを個別にインストールし、正しいCPU機能(またはその欠如)でコンパイルをトリガーすることです。
これをapp.ymlで試す予定でした。
hooks:
before_code:
- exec:
cmd:
- gem install oj
しかし、フォーラムのダウンタイムをこれ以上増やす余裕はありません。
その特定のセキュリティアップデートは、共有ホスティング環境ではないため、私には関連がないようです。Dockerの情報をどのように解釈すればよいかわかりません。以下はpsです。
37c258b23221 local_discourse/app 「/sbin/boot」 3か月前 Exited (7) 3時間前
以下はイメージリストです。
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20220621-0049 a44ca4f67972 3週間前 2.65GB
local_discourse/app latest b5f2a8a39709 3か月前 3.53GB
discourse/base 2.0.20220413-0411 ab71a5d97460 3か月前 2.81GB
<none> <none> 58ba7d1c8d7a 3か月前 3.74GB
discourse/base 2.0.20220224-2005 cd112601450a 4か月前 2.84GB
<none> <none> d9cf1feb92fd 6か月前 3.19GB
<none> <none> d53ee33f6fe1 6か月前 3.19GB
<none> <none> 14f79500c49c 6か月前 3.19GB
<none> <none> edff9b614f46 6か月前 3.19GB
<none> <none> e2348b41f937 6か月前 3.19GB
<none> <none> 42f6511b414c 6か月前 3.19GB
<none> <none> 3086f92af2fe 6か月前 3.19GB
<none> <none> 6ada029723ba 6か月前 3.19GB
<none> <none> ca61149580d4 6か月前 3.19GB
<none> <none> ce5ae3bb62ac 6か月前 3.19GB
<none> <none> e9a5c1b1aed4 6か月前 3.19GB
<none> <none> 6bb94ce1e01f 6か月前 3.19GB
<none> <none> e1df4acbd927 6か月前 3.19GB
<none> <none> 7e05a0b160c5 6か月前 3.19GB
<none> <none> 979926f28a73 6か月前 3.19GB
<none> <none> d055f9b01556 6か月前 3.19GB
<none> <none> aa0c779093dc 6か月前 3.19GB
discourse/base 2.0.20211118-0105 b6cc7cf8974a 7か月前 2.58GB
discourse/base 2.0.20210528-1735 482386bf57af 13か月前 2.36GB
<none> <none> e6011d2b206c 14か月前 2.69GB
discourse/base 2.0.20210415-1332 30e4746e631e 15か月前 2.23GB
<none> <none> 8066ac13b8c3 17か月前 2.45GB
discourse/base 2.0.20201221-2020 c0704d4ce2b4 18か月前 2.11GB
<none> <none> 043da6b3335d 2年前 2.4GB
discourse/base 2.0.20200429-2110 dc919e1dae2c 2年前 2.13GB
<none> <none> ff15472f4794 2年前 2.79GB
discourse/base 2.0.20191013-2320 09725007dc9e 2年前 2.3GB
<none> <none> f65391a062f0 2年前 2.62GB
discourse/base 2.0.20190901-2315 10f636afbeaf 2年前 2.29GB
<none> <none> 6944d06786b4 2年前 2.31GB
discourse/base 2.0.20190625-0946 2b3a5b47565f 3年前 1.93GB
<none> <none> 60b39deba7d2 3年前 2.3GB
discourse/base 2.0.20190505-2322 ed87227f60d2 3年前 1.91GB
<none> <none> cc5c0e56298c 3年前 2.38GB
discourse/base 2.0.20190321-0122 7db99586b5b5 3年前 1.97GB
<none> <none> b19f9a483788 3年前 2.27GB
discourse/base 2.0.20190217 9c24db193c37 3年前 1.92GB
hello-world latest fce289e99eb9 3年前 1.84kB
<none> <none> 614db6988e9c 3年前 2.25GB
<none> <none> 729b196da862 3年前 2.25GB
<none> <none> 80584ec5ec01 3年前 2.25GB
<none> <none> 0e2481aefed8 3年前 2.25GB
<none> <none> 725d0c17a6bb 3年前 2.25GB
<none> <none> 220bed95d236 3年前 2.25GB
<none> <none> fca469dba597 3年前 2.25GB
<none> <none> edab31d0ffce 3年前 2.25GB
<none> <none> dbacaff2d35e 3年前 2.25GB
<none> <none> 3d6a0453da1d 3年前 2.25GB
<none> <none> fbf0529eb303 3年前 2.25GB
<none> <none> 7a45443ae44c 3年前 2.25GB
<none> <none> ad90d7f42416 3年前 2.25GB
<none> <none> d61ea07d6084 3年前 2.25GB
<none> <none> d393fd8b4de0 3年前 2.25GB
discourse/base 2.0.20181031 ea31cd77735a 3年前 1.88GB
./launcher start app を試していただけますか?