O core dump e a instrução inválida indicam que algo está dando errado em um nível baixo (CPU, memória).
Não sou um especialista em hardware, mas essa CPU chegou ao mercado há 12 anos e suspeito que possa ser muito antiga (ou seja, ela está tentando executar código compilado que assume uma CPU mais nova).
Nós pensamos sobre isso, mas dado que tem funcionado bem nos últimos três anos, o que teria sido atualizado na stack que de repente requer uma instrução mais nova? (Além disso, qual/quais instrução?)
FEATURE: Add support for clear_every parameter in Redis backend (#309) · discourse/message_bus@1baa1ea · GitHub estaria acionando algum comportamento diferente dentro do Redis? 
Também quero acrescentar que na última sexta-feira a atualização de versão principal foi realizada sem problemas e funcionou durante todo o fim de semana sem falhas. Eu até realizei uma atualização bem-sucedida no domingo. Se for a CPU, o que é compreensível, a causa, então teria mostrado este erro com a atualização de versão principal.
Mas, talvez tenha havido uma mudança desde segunda-feira…
Isso pode muito bem ser, está travando em uma rotina de análise de json, no código do message bus, embora essa alteração que você mencionou tenha mais de 4 meses.
-- Informações de backtrace do nível 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]
-- Informações do frame de controle ----------------------------------------------
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]
Sim… então já deveria estar presente no domingo. 
Olhando os logs, parece que já existe outra instância do redis rodando quando ele tenta iniciar.
Isso pode ser o problema?
102:C 05 Jul 2022 09:53:34.597 # oO0OoO0OoO0Oo Redis está iniciando oO0OoO0OoO0Oo
102:C 05 Jul 2022 09:53:34.597 # Versão do Redis=6.2.6, bits=64, commit=00000000, modificado=0, pid=102, recém-iniciado
102:C 05 Jul 2022 09:53:34.597 # Configuração carregada
102:M 05 Jul 2022 09:53:34.598 * Relógio monotônico: POSIX clock_gettime
102:M 05 Jul 2022 09:53:34.599 * Modo de execução=standalone, porta=6379.
102:M 05 Jul 2022 09:53:34.599 # Servidor inicializado
102:M 05 Jul 2022 09:53:34.599 # AVISO overcommit_memory está definido como 0! O salvamento em segundo plano pode falhar sob condições de pouca memória. Para corrigir este problema, adicione 'vm.overcommit_memory = 1' a /etc/sysctl.conf e, em seguida, reinicie ou execute o comando 'sysctl vm.overcommit_memory=1' para que isso tenha efeito.
102:M 05 Jul 2022 09:53:34.599 * Carregando RDB produzido pela versão 6.2.6
102:M 05 Jul 2022 09:53:34.599 * Idade do RDB 1972 segundos
102:M 05 Jul 2022 09:53:34.599 * Uso de memória do RDB quando criado 60.60 Mb
102:M 05 Jul 2022 09:53:34.949 # RDB carregado, chaves carregadas: 8005, chaves expiradas: 9.
102:M 05 Jul 2022 09:53:34.950 * DB carregado do disco: 0.351 segundos
102:M 05 Jul 2022 09:53:34.950 * Pronto para aceitar conexões
129:C 05 Jul 2022 09:53:45.056 # oO0OoO0OoO0Oo Redis está iniciando oO0OoO0OoO0Oo
129:C 05 Jul 2022 09:53:45.056 # Versão do Redis=6.2.6, bits=64, commit=00000000, modificado=0, pid=129, recém-iniciado
129:C 05 Jul 2022 09:53:45.056 # Configuração carregada
129:M 05 Jul 2022 09:53:45.057 * Relógio monotônico: POSIX clock_gettime
129:M 05 Jul 2022 09:53:45.057 # Aviso: Não foi possível criar o socket de escuta TCP do servidor *:6379: bind: Endereço já em uso
129:M 05 Jul 2022 09:53:45.057 # Falha ao escutar na porta 6379 (TCP), abortando.
102:signal-handler (1657015415) SIGTERM recebido, agendando desligamento...
102:M 05 Jul 2022 10:03:35.245 # Desligamento solicitado pelo usuário...
102:M 05 Jul 2022 10:03:35.245 * Salvando o snapshot final do RDB antes de sair.
102:M 05 Jul 2022 10:03:39.882 * DB salvo em disco
102:M 05 Jul 2022 10:03:39.882 # Redis está pronto para sair, até mais...
Isso é bem normal para um launcher rebuild app - não afeta nada (pelo que sei, pelo menos…).
Os caminhos do código também podem ser acionados com a presença ou ausência de determinados dados. Talvez o código ofensivo estivesse presente, mas não estava sendo executado.
Vou tentar uma espécie de busca binária no último conjunto de commits e ver se consigo reduzir a um commit recente específico. Isso levará “algum tempo”… 
Editar:
Ok, então o primeiro commit com falha e instrução ilegal é Build(deps): Bump oj from 3.13.14 to 3.13.15 (#17309) · discourse/discourse@4c69619 · GitHub que está vinculado a Fix NaN object dump issue · ohler55/oj@f0122cf · GitHub
Alguns commits anteriores também falham na compilação, mas com um problema diferente (que também parece ser transitório…):
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.
Boa descoberta, está realmente travando na gem oj.
A versão 3.13.15 também contém este commit que muda para usar instruções SSE 4.2 para desempenho. E estas não são suportadas em processadores AMD Opteron 41xx.
Então voltamos a
IMHO É péssimo que o autor da gem tenha escolhido tornar isso uma decisão em tempo de compilação.
Adorável. Uma alteração adicional não mencionada no changelog do oj… 
Portanto, se a gem não fizer sua compilação nativa durante a instalação (então poderíamos potencialmente forçá-la a funcionar via OJ_USE_SSE4_2), parece que precisaremos de uma mudança de servidor… 
Editar: a gem não distribui nenhum objeto pré-compilado, então isso deve ser viável - então a próxima pergunta é por que ela está compilando com SSE4.2 em um sistema que não o suporta.
Nossa imagem base atual envia 3.13.14, então está sendo compilada em seu sistema.
Você pode tentar reproduzir o erro com o script de benchmark do commit:
○ → 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;
Você também pode verificar se foi compilado usando a instrução problemática com:
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
Se sim, isso provavelmente é algo para relatar ao projeto da gem oj.
Gostaria de investigar isso um pouco mais, mas 1) quero evitar mais tempo de inatividade (por enquanto, pelo menos; sei que o acima não envolve tempo de inatividade, mas posso ser tentado a tentar outras coisas) e 2) quando isso mudar:
para 3.13.15 e a imagem base do Discourse herdar o mesmo requisito mínimo de microarquitetura de CPU, então o servidor atual não será sustentável de qualquer maneira (a menos que haja uma maneira de contornar isso, como (re)instalar a gema separadamente, por exemplo, como parte de um hook pré-código, mas eu também acho que isso seria um incômodo para a maioria das pessoas).
Isso também levanta a questão de qual seria uma data de corte razoável para o suporte de hardware; não é razoável esperar suporte para CPU de 32 bits, então talvez SSE4.2 seja um “novo mínimo” razoável para software moderno.
De fato, já levantei isso internamente.
Olá!
Obrigado por investigar isso. Estou tendo o mesmo problema em um Intel Atom N2800 (do final de 2011).
Você acha que pode haver uma maneira de contornar esse problema ou a única coisa que posso fazer por enquanto é migrar para hardware mais novo?
Obrigado,
Estou em maus lençóis agora com meu fórum com a atualização que me foi solicitada hoje. Nunca vi nenhum aviso sobre a futura obsolescência de nenhuma CPU e ter isso acontecido repentinamente é… ruim. Os servidores disponíveis têm todos a mesma configuração para consistência e todos usam a mesma CPU.
AMD Athlon™ II X2 B22 Processor
Não é prático sair e comprar um novo servidor, configurar, etc. nesta economia, mesmo com o tempo.
Como posso reverter esta atualização até que esta situação seja melhor compreendida? Não consigo nem mesmo contatar meus usuários agora com o fórum inativo. Obrigado.
Se você estiver usando o método de implantação Docker, pode ter um contêiner mais antigo que pode reiniciar (verifique, por exemplo, docker images e/ou docker ps -a).
Você também pode substituir o commit usado para construir a instância do Discourse editando app.yml e definindo a versão para o commit anterior à alteração, e então reconstruindo:
params:
version: adb7fa5e2fc51308efc9fc4ee57ecb1c15a85cfa
O Discourse quebrará novamente se você atualizar depois disso, o que não é ideal, dada a atualização de segurança que foi lançada desde então (embora o potencial de exploração pareça bastante limitado para a maioria das instâncias).
Uma opção (que ainda não tentei) é instalar a gem oj separadamente e esperar acionar a compilação com os recursos corretos (ou a falta deles) da CPU.
Eu planejei tentar isso em app.yml:
hooks:
before_code:
- exec:
cmd:
- gem install oj
mas eu não tenho escopo para mais tempo de inatividade do fórum.
Essa atualização de segurança específica não parece relevante para mim, pois não estou em um ambiente de hospedagem compartilhada. Não tenho certeza de como interpretar as informações do docker. Aqui está o ps:
37c258b23221 local_discourse/app “"/sbin/boot"” 3 meses atrás Exited (7) 3 horas atrás
Aqui está a lista de imagens:
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20220621-0049 a44ca4f67972 3 semanas atrás 2.65GB
local_discourse/app latest b5f2a8a39709 3 meses atrás 3.53GB
discourse/base 2.0.20220413-0411 ab71a5d97460 3 meses atrás 2.81GB
<none> <none> 58ba7d1c8d7a 3 meses atrás 3.74GB
discourse/base 2.0.20220224-2005 cd112601450a 4 meses atrás 2.84GB
<none> <none> d9cf1feb92fd 6 meses atrás 3.19GB
<none> <none> d53ee33f6fe1 6 meses atrás 3.19GB
<none> <none> 14f79500c49c 6 meses atrás 3.19GB
<none> <none> edff9b614f46 6 meses atrás 3.19GB
<none> <none> e2348b41f937 6 meses atrás 3.19GB
<none> <none> 42f6511b414c 6 meses atrás 3.19GB
<none> <none> 3086f92af2fe 6 meses atrás 3.19GB
<none> <none> 6ada029723ba 6 meses atrás 3.19GB
<none> <none> ca61149580d4 6 meses atrás 3.19GB
<none> <none> ce5ae3bb62ac 6 meses atrás 3.19GB
<none> <none> e9a5c1b1aed4 6 meses atrás 3.19GB
<none> <none> 6bb94ce1e01f 6 meses atrás 3.19GB
<none> <none> e1df4acbd927 6 meses atrás 3.19GB
<none> <none> 7e05a0b160c5 6 meses atrás 3.19GB
<none> <none> 979926f28a73 6 meses atrás 3.19GB
<none> <none> d055f9b01556 6 meses atrás 3.19GB
<none> <none> aa0c779093dc 6 meses atrás 3.19GB
discourse/base 2.0.20211118-0105 b6cc7cf8974a 7 meses atrás 2.58GB
discourse/base 2.0.20210528-1735 482386bf57af 13 meses atrás 2.36GB
<none> <none> e6011d2b206c 14 meses atrás 2.69GB
discourse/base 2.0.20210415-1332 30e4746e631e 15 meses atrás 2.23GB
<none> <none> 8066ac13b8c3 17 meses atrás 2.45GB
discourse/base 2.0.20201221-2020 c0704d4ce2b4 18 meses atrás 2.11GB
<none> <none> 043da6b3335d 2 anos atrás 2.4GB
discourse/base 2.0.20200429-2110 dc919e1dae2c 2 anos atrás 2.13GB
<none> <none> ff15472f4794 2 anos atrás 2.79GB
discourse/base 2.0.20191013-2320 09725007dc9e 2 anos atrás 2.3GB
<none> <none> f65391a062f0 2 anos atrás 2.62GB
discourse/base 2.0.20190901-2315 10f636afbeaf 2 anos atrás 2.29GB
<none> <none> 6944d06786b4 2 anos atrás 2.31GB
discourse/base 2.0.20190625-0946 2b3a5b47565f 3 anos atrás 1.93GB
<none> <none> 60b39deba7d2 3 anos atrás 2.3GB
discourse/base 2.0.20190505-2322 ed87227f60d2 3 anos atrás 1.91GB
<none> <none> cc5c0e56298c 3 anos atrás 2.38GB
discourse/base 2.0.20190321-0122 7db99586b5b5 3 anos atrás 1.97GB
<none> <none> b19f9a483788 3 anos atrás 2.27GB
discourse/base 2.0.20190217 9c24db193c37 3 anos atrás 1.92GB
hello-world latest fce289e99eb9 3 anos atrás 1.84kB
<none> <none> 614db6988e9c 3 anos atrás 2.25GB
<none> <none> 729b196da862 3 anos atrás 2.25GB
<none> <none> 80584ec5ec01 3 anos atrás 2.25GB
<none> <none> 0e2481aefed8 3 anos atrás 2.25GB
<none> <none> 725d0c17a6bb 3 anos atrás 2.25GB
<none> <none> 220bed95d236 3 anos atrás 2.25GB
<none> <none> fca469dba597 3 anos atrás 2.25GB
<none> <none> edab31d0ffce 3 anos atrás 2.25GB
<none> <none> dbacaff2d35e 3 anos atrás 2.25GB
<none> <none> 3d6a0453da1d 3 anos atrás 2.25GB
<none> <none> fbf0529eb303 3 anos atrás 2.25GB
<none> <none> 7a45443ae44c 3 anos atrás 2.25GB
<none> <none> ad90d7f42416 3 anos atrás 2.25GB
<none> <none> d61ea07d6084 3 anos atrás 2.25GB
<none> <none> d393fd8b4de0 3 anos atrás 2.25GB
discourse/base 2.0.20181031 ea31cd77735a 3 anos atrás 1.88GB
Você pode tentar um ./launcher start app?