Il core dump e l’istruzione non valida indicano che qualcosa non va a basso livello (CPU, memoria).
Non sono un esperto di hardware, ma questa CPU è arrivata sul mercato 12 anni fa e sospetto che possa essere troppo vecchia (cioè, sta cercando di eseguire codice compilato che presuppone una CPU più recente).
Ci abbiamo pensato, ma dato che ha funzionato bene negli ultimi tre anni, cosa sarebbe stato aggiornato nello stack che improvvisamente richiede un’istruzione più recente? (Inoltre, quale/quali istruzioni?)
FEATURE: Add support for clear_every parameter in Redis backend (#309) · discourse/message_bus@1baa1ea · GitHub potrebbe innescare un comportamento diverso all’interno di Redis? 
Voglio anche aggiungere che venerdì scorso l’aggiornamento della versione principale è stato eseguito senza intoppi e ha funzionato per tutto il fine settimana senza problemi. Ho persino eseguito un aggiornamento di successo domenica. Se la causa è la CPU, il che è comprensibile, allora avrebbe mostrato questo errore con l’aggiornamento della versione principale.
Ma, forse c’è stato un cambiamento da lunedì…
Potrebbe essere benissimo, si sta bloccando in una routine di analisi JSON, nel codice del message bus, anche se la modifica che hai menzionato risale a oltre 4 mesi fa.
-- Informazioni sul backtrace a livello 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]
-- Informazioni sul frame di controllo ----------------------------------------------
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ì… quindi avrebbe già dovuto essere presente domenica. 
Esaminando i log, sembra che ci sia già un’altra istanza di redis in esecuzione quando tenta di avviarla.
Può essere questo il problema?
102:C 05 Jul 2022 09:53:34.597 # oO0OoO0OoO0Oo Redis sta partendo oO0OoO0OoO0Oo
102:C 05 Jul 2022 09:53:34.597 # Versione Redis=6.2.6, bit=64, commit=00000000, modificato=0, pid=102, appena avviato
102:C 05 Jul 2022 09:53:34.597 # Caricata configurazione
102:M 05 Jul 2022 09:53:34.598 * Orologio monotono: POSIX clock_gettime
102:M 05 Jul 2022 09:53:34.599 * Modalità di esecuzione=standalone, porta=6379.
102:M 05 Jul 2022 09:53:34.599 # Server inizializzato
102:M 05 Jul 2022 09:53:34.599 # ATTENZIONE overcommit_memory è impostato su 0! Il salvataggio in background potrebbe fallire in condizioni di memoria insufficiente. Per risolvere questo problema, aggiungi 'vm.overcommit_memory = 1' a /etc/sysctl.conf e quindi riavvia o esegui il comando 'sysctl vm.overcommit_memory=1' affinché abbia effetto.
102:M 05 Jul 2022 09:53:34.599 * Caricamento RDB prodotto dalla versione 6.2.6
102:M 05 Jul 2022 09:53:34.599 * Età RDB 1972 secondi
102:M 05 Jul 2022 09:53:34.599 * Utilizzo memoria RDB al momento della creazione 60.60 Mb
102:M 05 Jul 2022 09:53:34.949 # Caricamento RDB completato, chiavi caricate: 8005, chiavi scadute: 9.
102:M 05 Jul 2022 09:53:34.950 * DB caricato dal disco: 0.351 secondi
102:M 05 Jul 2022 09:53:34.950 * Pronto per accettare connessioni
129:C 05 Jul 2022 09:53:45.056 # oO0OoO0OoO0Oo Redis sta partendo oO0OoO0OoO0Oo
129:C 05 Jul 2022 09:53:45.056 # Versione Redis=6.2.6, bit=64, commit=00000000, modificato=0, pid=129, appena avviato
129:C 05 Jul 2022 09:53:45.056 # Caricata configurazione
129:M 05 Jul 2022 09:53:45.057 * Orologio monotono: POSIX clock_gettime
129:M 05 Jul 2022 09:53:45.057 # Avviso: Impossibile creare il socket di ascolto TCP del server *:6379: bind: Indirizzo già in uso
129:M 05 Jul 2022 09:53:45.057 # Impossibile ascoltare sulla porta 6379 (TCP), interruzione.
102:signal-handler (1657015415) Ricevuto SIGTERM pianificazione spegnimento...
102:M 05 Jul 2022 10:03:35.245 # Spegnimento richiesto dall'utente...
102:M 05 Jul 2022 10:03:35.245 * Salvataggio dello snapshot RDB finale prima di uscire.
102:M 05 Jul 2022 10:03:39.882 * DB salvato su disco
102:M 05 Jul 2022 10:03:39.882 # Redis è ora pronto per uscire, arrivederci...
Questo è abbastanza normale per un launcher rebuild app - non influisce su nulla (per quanto ne so, almeno…).
I percorsi del codice possono anche attivarsi in base alla presenza o all’assenza di determinati dati. Forse il codice incriminato era presente ma non veniva eseguito.
Proverò un quasi-bisecting sull’ultimo set di commit per vedere se riesco a restringere il campo a una modifica recente specifica. Ci vorrà “un po’ di tempo”… 
Modifica:
OK, quindi il primo commit errato con l’istruzione illegale è Build(deps): Bump oj from 3.13.14 to 3.13.15 (#17309) · discourse/discourse@4c69619 · GitHub che è collegato a Fix NaN object dump issue · ohler55/oj@f0122cf · GitHub
Alcuni commit precedenti falliscono anche nella compilazione, ma con un problema diverso (che sembra anch’esso 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.
Ottima scoperta, sta effettivamente andando in crash nella gemma oj.
La versione 3.13.15 contiene anche questo commit che passa all’uso delle istruzioni SSE 4.2 per le prestazioni. E queste non sono supportate sui processori AMD Opteron 41xx.
Quindi siamo tornati a
IMHO fa schifo che l’autore della gemma abbia scelto di renderlo una decisione al momento della compilazione.
Bello. Una modifica aggiuntiva non menzionata nel changelog di oj… 
Quindi, se la gemma non esegue la sua compilazione nativa durante l’installazione (quindi potremmo potenzialmente farla funzionare tramite OJ_USE_SSE4_2), sembra che sarà necessario spostare il server… 
Modifica: la gemma non distribuisce oggetti precompilati, quindi dovrebbe essere fattibile - la domanda successiva è perché sta compilando con SSE4.2 su un sistema che non lo supporta.
La nostra immagine di base attuale include la versione 3.13.14, quindi viene compilata sul tuo sistema.
Puoi provare a riprodurre l’errore con lo script di benchmark dal 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;
Puoi anche verificare se è stato compilato utilizzando l’istruzione problematica 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
Se è così, questo è probabilmente qualcosa da segnalare al progetto della gem oj.
Voglio approfondire la questione, ma 1) voglio evitare ulteriori interruzioni (almeno per un po’; so che quanto sopra non comporta interruzioni, ma potrei essere tentato di provare altre cose) e 2) quando questo cambia:
alla 3.13.15 e l’immagine di base di Discourse eredita lo stesso requisito minimo di microarchitettura della CPU, allora il server attuale non sarà comunque sostenibile (a meno che non ci sia un modo per aggirarlo, come (re)installare il gem separatamente, ad esempio come parte di un hook pre-codice, ma suppongo anche che sia un po’ complicato per la maggior parte delle persone).
Solleva anche la questione di quale dovrebbe essere una data limite ragionevole per il supporto hardware; non è ragionevole aspettarsi il supporto per CPU a 32 bit, quindi forse SSE4.2 è un “nuovo minimo” ragionevole per il software moderno.
Infatti, l’ho già sollevato internamente.
Ciao!
Grazie per aver indagato su questo. Sto riscontrando lo stesso problema su un Intel Atom N2800 (dalla fine del 2011).
Pensi che ci possa essere un modo per aggirare questo problema o l’unica cosa che posso fare per ora è migrare a hardware più recente?
Grazie,
Sono bloccato adesso con il mio forum a causa dell’aggiornamento che mi è stato richiesto oggi. Non ho mai visto alcun avviso riguardo all’obsolescenza imminente di alcuna CPU, e che questo accada improvvisamente è… negativo. I server disponibili hanno tutti la stessa configurazione per coerenza e utilizzano tutti la stessa CPU.
AMD Athlon™ II X2 B22 Processor
Non è pratico uscire e comprare un nuovo server, configurarlo, ecc. in questa economia, anche considerando il tempo.
Come posso annullare questo aggiornamento finché questa situazione non sarà meglio compresa? Non posso nemmeno contattare i miei utenti in questo momento con il forum bloccato. Grazie.
Se stai utilizzando il metodo di distribuzione Docker, potresti avere un container più vecchio che puoi riavviare (controlla ad esempio docker images e/o docker ps -a).
Puoi anche sovrascrivere il commit utilizzato per creare l’istanza di Discourse modificando app.yml e impostando la versione sul commit precedente alla modifica, quindi ricompilando:
params:
version: adb7fa5e2fc51308efc9fc4ee57ecb1c15a85cfa
Discourse si interromperà di nuovo se aggiorni dopo questo, il che non è l’ideale dato l’aggiornamento di sicurezza che è stato rilasciato da allora (sebbene il potenziale di sfruttamento sembri piuttosto limitato per la maggior parte delle istanze).
Un’opzione (che non ho ancora provato) è installare separatamente la gemma oj e sperare di innescare la compilazione con le corrette funzionalità della CPU (o la loro assenza).
Avevo pianificato di provarci in app.yml:
hooks:
before_code:
- exec:
cmd:
- gem install oj
ma non ho tempo per ulteriori tempi di inattività del forum.
Quell’aggiornamento di sicurezza specifico non mi sembra pertinente poiché non mi trovo in un ambiente di hosting condiviso. Non sono sicuro di come interpretare le informazioni di docker. Ecco il ps:
37c258b23221 local_discourse/app " /sbin/boot " 3 mesi fa Uscito (7) 3 ore fa
Ecco l’elenco delle immagini:
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20220621-0049 a44ca4f67972 3 settimane fa 2.65GB
local_discourse/app latest b5f2a8a39709 3 mesi fa 3.53GB
discourse/base 2.0.20220413-0411 ab71a5d97460 3 mesi fa 2.81GB
<none> <none> 58ba7d1c8d7a 3 mesi fa 3.74GB
discourse/base 2.0.20220224-2005 cd112601450a 4 mesi fa 2.84GB
<none> <none> d9cf1feb92fd 6 mesi fa 3.19GB
<none> <none> d53ee33f6fe1 6 mesi fa 3.19GB
<none> <none> 14f79500c49c 6 mesi fa 3.19GB
<none> <none> edff9b614f46 6 mesi fa 3.19GB
<none> <none> e2348b41f937 6 mesi fa 3.19GB
<none> <none> 42f6511b414c 6 mesi fa 3.19GB
<none> <none> 3086f92af2fe 6 mesi fa 3.19GB
<none> <none> 6ada029723ba 6 mesi fa 3.19GB
<none> <none> ca61149580d4 6 mesi fa 3.19GB
<none> <none> ce5ae3bb62ac 6 mesi fa 3.19GB
<none> <none> e9a5c1b1aed4 6 mesi fa 3.19GB
<none> <none> 6bb94ce1e01f 6 mesi fa 3.19GB
<none> <none> e1df4acbd927 6 mesi fa 3.19GB
<none> <none> 7e05a0b160c5 6 mesi fa 3.19GB
<none> <none> 979926f28a73 6 mesi fa 3.19GB
<none> <none> d055f9b01556 6 mesi fa 3.19GB
<none> <none> aa0c779093dc 6 mesi fa 3.19GB
discourse/base 2.0.20211118-0105 b6cc7cf8974a 7 mesi fa 2.58GB
discourse/base 2.0.20210528-1735 482386bf57af 13 mesi fa 2.36GB
<none> <none> e6011d2b206c 14 mesi fa 2.69GB
discourse/base 2.0.20210415-1332 30e4746e631e 15 mesi fa 2.23GB
<none> <none> 8066ac13b8c3 17 mesi fa 2.45GB
discourse/base 2.0.20201221-2020 c0704d4ce2b4 18 mesi fa 2.11GB
<none> <none> 043da6b3335d 2 anni fa 2.4GB
discourse/base 2.0.20200429-2110 dc919e1dae2c 2 anni fa 2.13GB
<none> <none> ff15472f4794 2 anni fa 2.79GB
discourse/base 2.0.20191013-2320 09725007dc9e 2 anni fa 2.3GB
<none> <none> f65391a062f0 2 anni fa 2.62GB
discourse/base 2.0.20190901-2315 10f636afbeaf 2 anni fa 2.29GB
<none> <none> 6944d06786b4 2 anni fa 2.31GB
discourse/base 2.0.20190625-0946 2b3a5b47565f 3 anni fa 1.93GB
<none> <none> 60b39deba7d2 3 anni fa 2.3GB
discourse/base 2.0.20190505-2322 ed87227f60d2 3 anni fa 1.91GB
<none> <none> cc5c0e56298c 3 anni fa 2.38GB
discourse/base 2.0.20190321-0122 7db99586b5b5 3 anni fa 1.97GB
<none> <none> b19f9a483788 3 anni fa 2.27GB
discourse/base 2.0.20190217 9c24db193c37 3 anni fa 1.92GB
hello-world latest fce289e99eb9 3 anni fa 1.84kB
<none> <none> 614db6988e9c 3 anni fa 2.25GB
<none> <none> 729b196da862 3 anni fa 2.25GB
<none> <none> 80584ec5ec01 3 anni fa 2.25GB
<none> <none> 0e2481aefed8 3 anni fa 2.25GB
<none> <none> 725d0c17a6bb 3 anni fa 2.25GB
<none> <none> 220bed95d236 3 anni fa 2.25GB
<none> <none> fca469dba597 3 anni fa 2.25GB
<none> <none> edab31d0ffce 3 anni fa 2.25GB
<none> <none> dbacaff2d35e 3 anni fa 2.25GB
<none> <none> 3d6a0453da1d 3 anni fa 2.25GB
<none> <none> fbf0529eb303 3 anni fa 2.25GB
<none> <none> 7a45443ae44c 3 anni fa 2.25GB
<none> <none> ad90d7f42416 3 anni fa 2.25GB
<none> <none> d61ea07d6084 3 anni fa 2.25GB
<none> <none> d393fd8b4de0 3 anni fa 2.25GB
discourse/base 2.0.20181031 ea31cd77735a 3 anni fa 1.88GB
Puoi provare un ./launcher start app?