La volcada del núcleo y la instrucción inválida indican que algo está fallando a bajo nivel (CPU, memoria).
No soy un experto en hardware, pero esta CPU salió al mercado hace 12 años y sospecho que podría ser demasiado antigua (es decir, está intentando ejecutar código compilado que asume una CPU más nueva).
Pensamos en esto, pero dado que ha estado funcionando bien durante los últimos tres años, ¿qué se habría actualizado dentro de la pila que de repente requiere una instrucción más nueva? (Además, ¿qué instrucción?)
¿FEATURE: Add support for clear_every parameter in Redis backend (#309) · discourse/message_bus@1baa1ea · GitHub estaría activando algún comportamiento diferente dentro de Redis? 
También quiero añadir que el viernes pasado se realizó la actualización de la versión principal sin problemas y funcionó todo el fin de semana sin inconvenientes. Incluso realicé una actualización exitosa el domingo. Si es la CPU, lo cual es comprensible, la causa entonces habría mostrado este error con la actualización de la versión principal.
Pero, quizás ha habido un cambio desde el lunes…
Eso podría ser, se está bloqueando en una rutina de análisis JSON, en el código del bus de mensajes, aunque ese cambio que mencionaste tiene más de 4 meses.
-- Información de rastreo de pila a nivel 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]
-- Información del marco de control -----------------------------------------------
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]
Sí… así que ya debería haber estado presente el domingo. 
Revisando los registros, parece que ya hay otra instancia de redis ejecutándose cuando intenta iniciarse.
¿Puede ser ese el problema?
102:C 05 Jul 2022 09:53:34.597 # oO0OoO0OoO0Oo Redis está iniciando oO0OoO0OoO0Oo
102:C 05 Jul 2022 09:53:34.597 # Versión de Redis=6.2.6, bits=64, commit=00000000, modificado=0, pid=102, recién iniciado
102:C 05 Jul 2022 09:53:34.597 # Configuración cargada
102:M 05 Jul 2022 09:53:34.598 * Reloj monotónico: POSIX clock_gettime
102:M 05 Jul 2022 09:53:34.599 * Modo de ejecución=standalone, puerto=6379.
102:M 05 Jul 2022 09:53:34.599 # Servidor inicializado
102:M 05 Jul 2022 09:53:34.599 # ADVERTENCIA overcommit_memory está configurado en 0! El guardado en segundo plano puede fallar en condiciones de poca memoria. Para solucionar este problema, agregue 'vm.overcommit_memory = 1' a /etc/sysctl.conf y luego reinicie o ejecute el comando 'sysctl vm.overcommit_memory=1' para que esto tenga efecto.
102:M 05 Jul 2022 09:53:34.599 * Cargando RDB producido por la versión 6.2.6
102:M 05 Jul 2022 09:53:34.599 * Edad del RDB 1972 segundos
102:M 05 Jul 2022 09:53:34.599 * Uso de memoria del RDB cuando se creó 60.60 Mb
102:M 05 Jul 2022 09:53:34.949 # Carga del RDB completada, claves cargadas: 8005, claves expiradas: 9.
102:M 05 Jul 2022 09:53:34.950 * DB cargada desde el disco: 0.351 segundos
102:M 05 Jul 2022 09:53:34.950 * Listo para aceptar conexiones
129:C 05 Jul 2022 09:53:45.056 # oO0OoO0OoO0Oo Redis está iniciando oO0OoO0OoO0Oo
129:C 05 Jul 2022 09:53:45.056 # Versión de Redis=6.2.6, bits=64, commit=00000000, modificado=0, pid=129, recién iniciado
129:C 05 Jul 2022 09:53:45.056 # Configuración cargada
129:M 05 Jul 2022 09:53:45.057 * Reloj monotónico: POSIX clock_gettime
129:M 05 Jul 2022 09:53:45.057 # Advertencia: No se pudo crear el socket de escucha TCP del servidor *:6379: bind: Dirección ya en uso
129:M 05 Jul 2022 09:53:45.057 # Falló la escucha en el puerto 6379 (TCP), abortando.
102:signal-handler (1657015415) Señal SIGTERM recibida, programando apagado...
102:M 05 Jul 2022 10:03:35.245 # El usuario solicitó el apagado...
102:M 05 Jul 2022 10:03:35.245 * Guardando la instantánea final del RDB antes de salir.
102:M 05 Jul 2022 10:03:39.882 * DB guardada en el disco
102:M 05 Jul 2022 10:03:39.882 # Redis está listo para salir, adiós...
Esto es bastante normal para un launcher rebuild app - no afecta a nada (hasta donde yo sé, al menos…).
Las rutas de código también pueden activarse ante la presencia o ausencia de ciertos datos. Quizás el código infractor estaba presente pero no se estaba ejecutando.
Voy a intentar una especie de “bisección” en el último conjunto de commits y veré si puedo reducirlo a un cambio reciente específico. Esto llevará “algo de tiempo”… 
Editar:
OK, así que el primer commit defectuoso con la instrucción ilegal es 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
Algunos commits anteriores también fallan al compilar, pero con un problema diferente (que también parece que podría ser transitorio…):
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.
Buen hallazgo, efectivamente está fallando en la gema oj.
La versión 3.13.15 también contiene este commit que cambia al uso de instrucciones SSE 4.2 para mejorar el rendimiento. Y estas no son compatibles con los procesadores AMD Opteron 41xx.
Así que volvemos a
En mi opinión, es una pena que el autor de la gema haya decidido que esta sea una decisión en tiempo de compilación.
Encantador. Un cambio adicional no mencionado en el registro de cambios de oj… 
Entonces, si la gema no realiza su compilación nativa durante la instalación (por lo que podríamos intentar que funcione a través de OJ_USE_SSE4_2), parece que necesitaremos mover el servidor… 
Editar: la gema no distribuye ningún objeto precompilado, por lo que esto debería ser viable. La siguiente pregunta es por qué se compila con SSE4.2 en un sistema que no lo admite.
Nuestra imagen base actual incluye la versión 3.13.14, por lo que se está compilando en tu sistema.
¿Puedes intentar reproducir el error con el script de benchmark del 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;
También puedes comprobar si se compiló o no utilizando la instrucción problemática con:
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
Si es así, probablemente sea algo que debas reportar al proyecto del gem oj.
Quiero investigar esto un poco más, pero 1) quiero evitar más tiempo de inactividad (al menos por un tiempo; sé que lo anterior no implica tiempo de inactividad, pero podría sentirme tentado a probar otras cosas) y 2) cuando esto cambie:
a 3.13.15 y la imagen base de Discourse hereda el mismo requisito mínimo de microarquitectura de CPU, entonces el servidor actual tampoco será sostenible (a menos que haya una forma de solucionarlo, como (re)instalar la gema por separado, por ejemplo, como parte de un hook de pre-código, pero también supongo que eso es un poco complicado para la mayoría de las personas).
También plantea la pregunta de cuál debería ser una fecha límite razonable para el soporte de hardware; no es razonable esperar soporte para CPU de 32 bits, por lo que quizás SSE4.2 sea un “nuevo mínimo” razonable para el software moderno.
De hecho, ya lo he planteado internamente.
¡Hola!
Gracias por investigar esto. Tengo el mismo problema en un Intel Atom N2800 (de finales de 2011).
¿Crees que podría haber una solución alternativa a este problema o lo único que puedo hacer por ahora es migrar a hardware más nuevo?
Gracias,
Ahora estoy en un callejón sin salida con mi foro debido a la actualización que se me solicitó hoy. Nunca vi ninguna advertencia sobre la próxima obsolescencia de ninguna CPU, y que esto suceda de repente es… malo. Los servidores disponibles tienen todos la misma configuración por consistencia, y todos usan la misma CPU.
AMD Athlon™ II X2 B22 Processor
No es práctico salir a comprar un servidor nuevo, configurarlo, etc. en esta economía, incluso dado el tiempo.
¿Cómo puedo deshacer esta actualización hasta que esta situación se entienda mejor? Ni siquiera puedo contactar a mis usuarios en este momento con el foro caído. Gracias.
Si estás utilizando el método de implementación de Docker, es posible que tengas un contenedor más antiguo que puedas reiniciar (consulta, por ejemplo, docker images y/o docker ps -a).
También puedes anular el commit utilizado para compilar la instancia de Discourse editando app.yml y estableciendo la versión en el commit anterior al cambio, y luego reconstruyendo:
params:
version: adb7fa5e2fc51308efc9fc4ee57ecb1c15a85cfa
Discourse volverá a fallar si actualizas después de esto, lo cual no es ideal dado el actualización de seguridad que se ha lanzado desde entonces (aunque el potencial de explotación parece bastante limitado para la mayoría de las instancias).
Una opción (que aún no he probado) es instalar la gema oj por separado y esperar que se compile con las características de CPU correctas (o la falta de ellas).
Había planeado intentar esto en app.yml:
hooks:
before_code:
- exec:
cmd:
- gem install oj
pero no tengo margen para más tiempo de inactividad del foro.
Esa actualización de seguridad específica no parece relevante para mí, ya que no estoy en un entorno de alojamiento compartido. No estoy seguro de cómo interpretar la información de docker. Aquí está el ps:
37c258b23221 local_discourse/app " /sbin/boot " Hace 3 meses Salió (7) hace 3 horas
Aquí está la lista de imágenes:
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20220621-0049 a44ca4f67972 3 semanas ago 2.65GB
local_discourse/app latest b5f2a8a39709 3 meses ago 3.53GB
discourse/base 2.0.20220413-0411 ab71a5d97460 3 meses ago 2.81GB
<none> <none> 58ba7d1c8d7a 3 meses ago 3.74GB
discourse/base 2.0.20220224-2005 cd112601450a 4 meses ago 2.84GB
<none> <none> d9cf1feb92fd 6 meses ago 3.19GB
<none> <none> d53ee33f6fe1 6 meses ago 3.19GB
<none> <none> 14f79500c49c 6 meses ago 3.19GB
<none> <none> edff9b614f46 6 meses ago 3.19GB
<none> <none> e2348b41f937 6 meses ago 3.19GB
<none> <none> 42f6511b414c 6 meses ago 3.19GB
<none> <none> 3086f92af2fe 6 meses ago 3.19GB
<none> <none> 6ada029723ba 6 meses ago 3.19GB
<none> <none> ca61149580d4 6 meses ago 3.19GB
<none> <none> ce5ae3bb62ac 6 meses ago 3.19GB
<none> <none> e9a5c1b1aed4 6 meses ago 3.19GB
<none> <none> 6bb94ce1e01f 6 meses ago 3.19GB
<none> <none> e1df4acbd927 6 meses ago 3.19GB
<none> <none> 7e05a0b160c5 6 meses ago 3.19GB
<none> <none> 979926f28a73 6 meses ago 3.19GB
<none> <none> d055f9b01556 6 meses ago 3.19GB
<none> <none> aa0c779093dc 6 meses ago 3.19GB
discourse/base 2.0.20211118-0105 b6cc7cf8974a 7 meses ago 2.58GB
discourse/base 2.0.20210528-1735 482386bf57af 13 meses ago 2.36GB
<none> <none> e6011d2b206c 14 meses ago 2.69GB
discourse/base 2.0.20210415-1332 30e4746e631e 15 meses ago 2.23GB
<none> <none> 8066ac13b8c3 17 meses ago 2.45GB
discourse/base 2.0.20201221-2020 c0704d4ce2b4 18 meses ago 2.11GB
<none> <none> 043da6b3335d 2 años ago 2.4GB
discourse/base 2.0.20200429-2110 dc919e1dae2c 2 años ago 2.13GB
<none> <none> ff15472f4794 2 años ago 2.79GB
discourse/base 2.0.20191013-2320 09725007dc9e 2 años ago 2.3GB
<none> <none> f65391a062f0 2 años ago 2.62GB
discourse/base 2.0.20190901-2315 10f636afbeaf 2 años ago 2.29GB
<none> <none> 6944d06786b4 2 años ago 2.31GB
discourse/base 2.0.20190625-0946 2b3a5b47565f 3 años ago 1.93GB
<none> <none> 60b39deba7d2 3 años ago 2.3GB
discourse/base 2.0.20190505-2322 ed87227f60d2 3 años ago 1.91GB
<none> <none> cc5c0e56298c 3 años ago 2.38GB
discourse/base 2.0.20190321-0122 7db99586b5b5 3 años ago 1.97GB
<none> <none> b19f9a483788 3 años ago 2.27GB
discourse/base 2.0.20190217 9c24db193c37 3 años ago 1.92GB
hello-world latest fce289e99eb9 3 años ago 1.84kB
<none> <none> 614db6988e9c 3 años ago 2.25GB
<none> <none> 729b196da862 3 años ago 2.25GB
<none> <none> 80584ec5ec01 3 años ago 2.25GB
<none> <none> 0e2481aefed8 3 años ago 2.25GB
<none> <none> 725d0c17a6bb 3 años ago 2.25GB
<none> <none> 220bed95d236 3 años ago 2.25GB
<none> <none> fca469dba597 3 años ago 2.25GB
<none> <none> edab31d0ffce 3 años ago 2.25GB
<none> <none> dbacaff2d35e 3 años ago 2.25GB
<none> <none> 3d6a0453da1d 3 años ago 2.25GB
<none> <none> fbf0529eb303 3 años ago 2.25GB
<none> <none> 7a45443ae44c 3 años ago 2.25GB
<none> <none> ad90d7f42416 3 años ago 2.25GB
<none> <none> d61ea07d6084 3 años ago 2.25GB
<none> <none> d393fd8b4de0 3 años ago 2.25GB
discourse/base 2.0.20181031 ea31cd77735a 3 años ago 1.88GB
¿Puedes intentar un ./launcher start app?