Der Core Dump und die ungültige Anweisung deuten darauf hin, dass auf einer niedrigen Ebene (CPU, Speicher) etwas schief geht.
Ich bin kein Hardware-Experte, aber diese CPU kam vor 12 Jahren auf den Markt und ich vermute, dass sie zu alt sein könnte (d. h. sie versucht, kompilierten Code auszuführen, der eine neuere CPU voraussetzt).
Wir haben darüber nachgedacht, aber da es in den letzten drei Jahren problemlos funktioniert hat, was hätte sich im Stack geändert, das plötzlich eine neuere Anweisung erfordert? (Außerdem, welche Anweisung?)
Würde FEATURE: Add support for clear_every parameter in Redis backend (#309) · discourse/message_bus@1baa1ea · GitHub ein anderes Verhalten innerhalb von Redis auslösen? 
Ich möchte auch hinzufügen, dass am letzten Freitag das Major-Versions-Upgrade nahtlos durchgeführt wurde und das gesamte Wochenende ohne Probleme lief. Ich habe sogar am Sonntag ein erfolgreiches Update durchgeführt. Wenn die CPU, was verständlich ist, die Ursache ist, dann hätte sie diesen Fehler bereits beim Major-Versions-Upgrade gezeigt.
Aber vielleicht hat sich seit Montag etwas geändert…
Das mag durchaus sein, es stürzt in einer JSON-Parse-Routine im Message-Bus-Code ab, obwohl die von Ihnen erwähnte Änderung über 4 Monate alt ist.
-- C-Level-Backtrace-Informationen -------------------------------------------
/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]
-- Control-Frame-Informationen ----------------------------------------------
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]
Ja… das hätte also schon am Sonntag vorhanden sein sollen. 
Wenn ich mir die Protokolle ansehe, scheint es, dass bereits eine andere Instanz von Redis läuft, wenn versucht wird, sie zu starten.
Kann das das Problem sein?
102:C 05 Jul 2022 09:53:34.597 # oO0OoO0OoO0Oo Redis startet oO0OoO0OoO0Oo
102:C 05 Jul 2022 09:53:34.597 # Redis Version=6.2.6, Bits=64, Commit=00000000, Modifiziert=0, PID=102, gerade gestartet
102:C 05 Jul 2022 09:53:34.597 # Konfiguration geladen
102:M 05 Jul 2022 09:53:34.598 * Monotonische Uhr: POSIX clock_gettime
102:M 05 Jul 2022 09:53:34.599 * Laufmodus=standalone, Port=6379.
102:M 05 Jul 2022 09:53:34.599 # Server initialisiert
102:M 05 Jul 2022 09:53:34.599 # WARNUNG overcommit_memory ist auf 0 gesetzt! Hintergrundspeicherung kann bei geringem Speicherplatz fehlschlagen. Um dieses Problem zu beheben, fügen Sie 'vm.overcommit_memory = 1' zu /etc/sysctl.conf hinzu und starten Sie dann neu oder führen Sie den Befehl 'sysctl vm.overcommit_memory=1' aus, damit er wirksam wird.
102:M 05 Jul 2022 09:53:34.599 * Lade RDB von Version 6.2.6
102:M 05 Jul 2022 09:53:34.599 * RDB Alter 1972 Sekunden
102:M 05 Jul 2022 09:53:34.599 * RDB Speicherverbrauch bei Erstellung 60,60 MB
102:M 05 Jul 2022 09:53:34.949 # RDB geladen, Schlüssel geladen: 8005, Schlüssel abgelaufen: 9.
102:M 05 Jul 2022 09:53:34.950 * DB von Festplatte geladen: 0,351 Sekunden
102:M 05 Jul 2022 09:53:34.950 * Bereit für Verbindungsannahme
129:C 05 Jul 2022 09:53:45.056 # oO0OoO0OoO0Oo Redis startet oO0OoO0OoO0Oo
129:C 05 Jul 2022 09:53:45.056 # Redis Version=6.2.6, Bits=64, Commit=00000000, Modifiziert=0, PID=129, gerade gestartet
129:C 05 Jul 2022 09:53:45.056 # Konfiguration geladen
129:M 05 Jul 2022 09:53:45.057 * Monotonische Uhr: POSIX clock_gettime
129:M 05 Jul 2022 09:53:45.057 # Warnung: Konnte kein Server-TCP-Listening-Socket erstellen *:6379: bind: Adresse bereits in Verwendung
129:M 05 Jul 2022 09:53:45.057 # Fehler beim Lauschen auf Port 6379 (TCP), Abbruch.
102:signal-handler (1657015415) SIGTERM empfangen, Herunterfahren wird geplant...
102:M 05 Jul 2022 10:03:35.245 # Benutzer hat Herunterfahren angefordert...
102:M 05 Jul 2022 10:03:35.245 * Speichere den finalen RDB-Snapshot vor dem Beenden.
102:M 05 Jul 2022 10:03:39.882 * DB auf Festplatte gespeichert
102:M 05 Jul 2022 10:03:39.882 # Redis ist nun bereit zum Beenden, auf Wiedersehen...
Das ist ziemlich normal für einen launcher rebuild app - es beeinträchtigt nichts (soweit ich weiß, zumindest…).
Code-Pfade können auch bei bestimmten vorhandenen oder fehlenden Daten ausgelöst werden. Möglicherweise war der fehlerhafte Code vorhanden, wurde aber nicht ausgeführt.
Ich werde versuchen, eine Art Binärsuche auf dem neuesten Satz von Commits durchzuführen und zu sehen, ob ich ihn auf eine bestimmte kürzliche Änderung eingrenzen kann. Das wird „etwas Zeit“ in Anspruch nehmen… 
Bearbeiten:
Der erste fehlerhafte Commit mit der illegalen Anweisung ist Build(deps): Bump oj from 3.13.14 to 3.13.15 (#17309) · discourse/discourse@4c69619 · GitHub, der mit Fix NaN object dump issue · ohler55/oj@f0122cf · GitHub verknüpft ist.
Einige frühere Commits schlagen ebenfalls fehl, aber mit einem anderen Problem (das auch vorübergehend zu sein scheint…):
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 Änderungen in 300 Sekunden. Speichere...
102:M 05 Jul 2022 12:14:44.312 * Hintergrundspeicherung gestartet von PID 709
709:C 05 Jul 2022 12:14:45.166 * DB auf Festplatte gespeichert
709:C 05 Jul 2022 12:14:45.169 * RDB: 1 MB Speicher von Copy-on-Write verwendet
102:M 05 Jul 2022 12:14:45.217 * Hintergrundspeicherung erfolgreich beendet
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'
Fehlende Yarn-Pakete:
Paket: ember-cli-deprecation-workflow
* Angegeben: ^2.1.0
* Installiert: (nicht installiert)
Führen Sie `yarn` aus, um fehlende Abhängigkeiten zu installieren.
Stack Trace und Fehlerbericht: /tmp/error.dump.ccfa3d8342a442ee6860db37ce7c7330.log
Ein Fehler ist im Konstruktor von ember-cli-dependency-checker unter /var/www/discourse/app/assets/javascripts/node_modules/ember-cli-dependency-checker aufgetreten.
error Command failed with exit code 1.
Guter Fund, es stürzt tatsächlich in der oj-Gem ab.
Version 3.13.15 enthält auch diesen Commit, der aus Leistungsgründen auf die Verwendung von SSE 4.2-Instruktionen umstellt. Und diese werden nicht auf AMD Opteron 41xx-Prozessoren unterstützt.
Also sind wir zurück bei
Meiner Meinung nach ist es schlecht, dass der Gem-Autor sich entschieden hat, dies zu einer Compile-Zeit-Entscheidung zu machen.
Schön. Eine zusätzliche Änderung, die nicht im oj-Changelog erwähnt wird… 
Wenn das Gem also seine native Kompilierung während der Installation nicht durchführt (sodass wir es potenziell über OJ_USE_SSE4_2 zum Laufen bringen könnten), sieht es so aus, als ob ein Serverwechsel erforderlich wäre… 
Bearbeitung: das Gem verteilt keine vorkompilierten Objekte, daher sollte dies machbar sein - die nächste Frage ist also, warum es mit SSE4.2 auf einem System kompiliert, das es nicht unterstützt.
Unser aktuelles Basis-Image liefert 3.13.14, daher wird es auf Ihrem System kompiliert.
Können Sie versuchen, den Fehler mit dem Benchmark-Skript aus dem Commit zu reproduzieren:
○ → 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;
Sie können auch überprüfen, ob es mit der problematischen Anweisung kompiliert wurde, mit:
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
Wenn ja, ist dies wahrscheinlich etwas, das Sie dem Projekt des oj-Gems melden sollten.
Ich möchte mir das noch etwas genauer ansehen, aber 1) möchte ich mehr Ausfallzeiten vermeiden (zumindest für eine Weile; ich weiß, dass das Obige keine Ausfallzeiten beinhaltet, aber ich könnte versucht sein, andere Dinge auszuprobieren) und 2) wenn sich dies ändert:
[Zitat=“Michael Brown, Beitrag:33, Thema:231862, Benutzername:supermathie”]
Unser aktuelles Basis-Image wird mit 3.13.14 ausgeliefert
[/Zitat]
auf 3.13.15 und das Discourse-Basis-Image erbt dieselbe Mindestanforderung an die CPU-Mikroarchitektur, dann ist der aktuelle Server sowieso nicht mehr nachhaltig (es sei denn, es gibt eine Möglichkeit, dies zu umgehen, z. B. durch (Neu-)Installation des Gem separat, z. B. als Teil eines Pre-Code-Hooks, aber ich würde auch vermuten, dass dies für die meisten Leute ein bisschen umständlich ist).
Es wirft auch die Frage auf, was ein angemessenes Enddatum für den Hardware-Support überhaupt sein sollte; es ist nicht zumutbar, 32-Bit-CPU-Support zu erwarten, daher ist SSE4.2 vielleicht ein angemessenes “neues Minimum” für moderne Software.
In der Tat, ich habe dies bereits intern angesprochen.
Hallo!
Vielen Dank, dass Sie sich darum kümmern. Ich habe das gleiche Problem mit einem Intel Atom N2800 (von Ende 2011).
Glauben Sie, dass es einen Ausweg aus diesem Problem gibt, oder ist das Einzige, was ich im Moment tun kann, auf neuere Hardware umsteigen?
Vielen Dank,
Ich bin jetzt mit meinem Forum am Ende, was das Update angeht, zu dem ich heute aufgefordert wurde. Ich habe keine Warnungen über die bevorstehende Veralterung von CPUs gesehen, und dass dies plötzlich passiert, ist … schlecht. Die verfügbaren Server haben alle die gleiche Konfiguration zur Konsistenz, und alle verwenden die gleiche CPU.
AMD Athlon™ II X2 B22 Prozessor
Es ist nicht praktikabel, in dieser Wirtschaftslage einen neuen Server zu kaufen, zu konfigurieren usw., selbst wenn die Zeit gegeben ist.
Wie kann ich dieses Update rückgängig machen, bis diese Situation besser verstanden ist? Ich kann meine Benutzer derzeit nicht einmal kontaktieren, da das Forum ausgefallen ist. Danke.
Wenn Sie die Docker-Bereitstellungsmethode verwenden, haben Sie möglicherweise einen älteren Container, den Sie neu starten können (prüfen Sie z. B. docker images und/oder docker ps -a).
Sie können auch den Commit überschreiben, der zum Erstellen der Discourse-Instanz verwendet wurde, indem Sie app.yml bearbeiten und die Version auf den Commit vor der Änderung setzen, und dann neu erstellen:
params:
version: adb7fa5e2fc51308efc9fc4ee57ecb1c15a85cfa
Discourse wird erneut fehlschlagen, wenn Sie danach ein Update durchführen, was angesichts des Sicherheitsupdates, das seitdem veröffentlicht wurde, nicht ideal ist (obwohl das Ausnutzungspotenzial für die meisten Instanzen ziemlich begrenzt zu sein scheint).
Eine Möglichkeit (die ich noch nicht ausprobiert habe) ist, das oj-Gem separat zu installieren und zu hoffen, dass die Kompilierung mit den richtigen CPU-Features (oder deren Fehlen) ausgelöst wird.
Ich hatte vor, dies in app.yml zu versuchen:
hooks:
before_code:
- exec:
cmd:
- gem install oj
aber ich habe nicht den Spielraum für weitere Forenausfallzeiten.
Diese spezifische Sicherheitsaktualisierung scheint für mich nicht relevant zu sein, da ich mich nicht in einer Shared-Hosting-Umgebung befinde. Ich bin mir nicht sicher, wie ich die Docker-Informationen interpretieren soll. Hier ist die ps:
37c258b23221 local_discourse/app „/sbin/boot“ 3 Monate her Beendet (7) vor 3 Stunden
Hier ist die Image-Liste:
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20220621-0049 a44ca4f67972 3 Wochen her 2,65GB
local_discourse/app latest b5f2a8a39709 3 Monate her 3,53GB
discourse/base 2.0.20220413-0411 ab71a5d97460 3 Monate her 2,81GB
<none> <none> 58ba7d1c8d7a 3 Monate her 3,74GB
discourse/base 2.0.20220224-2005 cd112601450a 4 Monate her 2,84GB
<none> <none> d9cf1feb92fd 6 Monate her 3,19GB
<none> <none> d53ee33f6fe1 6 Monate her 3,19GB
<none> <none> 14f79500c49c 6 Monate her 3,19GB
<none> <none> edff9b614f46 6 Monate her 3,19GB
<none> <none> e2348b41f937 6 Monate her 3,19GB
<none> <none> 42f6511b414c 6 Monate her 3,19GB
<none> <none> 3086f92af2fe 6 Monate her 3,19GB
<none> <none> 6ada029723ba 6 Monate her 3,19GB
<none> <none> ca61149580d4 6 Monate her 3,19GB
<none> <none> ce5ae3bb62ac 6 Monate her 3,19GB
<none> <none> e9a5c1b1aed4 6 Monate her 3,19GB
<none> <none> 6bb94ce1e01f 6 Monate her 3,19GB
<none> <none> e1df4acbd927 6 Monate her 3,19GB
<none> <none> 7e05a0b160c5 6 Monate her 3,19GB
<none> <none> 979926f28a73 6 Monate her 3,19GB
<none> <none> d055f9b01556 6 Monate her 3,19GB
<none> <none> aa0c779093dc 6 Monate her 3,19GB
discourse/base 2.0.20211118-0105 b6cc7cf8974a 7 Monate her 2,58GB
discourse/base 2.0.20210528-1735 482386bf57af 13 Monate her 2,36GB
<none> <none> e6011d2b206c 14 Monate her 2,69GB
discourse/base 2.0.20210415-1332 30e4746e631e 15 Monate her 2,23GB
<none> <none> 8066ac13b8c3 17 Monate her 2,45GB
discourse/base 2.0.20201221-2020 c0704d4ce2b4 18 Monate her 2,11GB
<none> <none> 043da6b3335d 2 Jahre her 2,4GB
discourse/base 2.0.20200429-2110 dc919e1dae2c 2 Jahre her 2,13GB
<none> <none> ff15472f4794 2 Jahre her 2,79GB
discourse/base 2.0.20191013-2320 09725007dc9e 2 Jahre her 2,3GB
<none> <none> f65391a062f0 2 Jahre her 2,62GB
discourse/base 2.0.20190901-2315 10f636afbeaf 2 Jahre her 2,29GB
<none> <none> 6944d06786b4 2 Jahre her 2,31GB
discourse/base 2.0.20190625-0946 2b3a5b47565f 3 Jahre her 1,93GB
<none> <none> 60b39deba7d2 3 Jahre her 2,3GB
discourse/base 2.0.20190505-2322 ed87227f60d2 3 Jahre her 1,91GB
<none> <none> cc5c0e56298c 3 Jahre her 2,38GB
discourse/base 2.0.20190321-0122 7db99586b5b5 3 Jahre her 1,97GB
<none> <none> b19f9a483788 3 Jahre her 2,27GB
discourse/base 2.0.20190217 9c24db193c37 3 Jahre her 1,92GB
hello-world latest fce289e99eb9 3 Jahre her 1,84kB
<none> <none> 614db6988e9c 3 Jahre her 2,25GB
<none> <none> 729b196da862 3 Jahre her 2,25GB
<none> <none> 80584ec5ec01 3 Jahre her 2,25GB
<none> <none> 0e2481aefed8 3 Jahre her 2,25GB
<none> <none> 725d0c17a6bb 3 Jahre her 2,25GB
<none> <none> 220bed95d236 3 Jahre her 2,25GB
<none> <none> fca469dba597 3 Jahre her 2,25GB
<none> <none> edab31d0ffce 3 Jahre her 2,25GB
<none> <none> dbacaff2d35e 3 Jahre her 2,25GB
<none> <none> 3d6a0453da1d 3 Jahre her 2,25GB
<none> <none> fbf0529eb303 3 Jahre her 2,25GB
<none> <none> 7a45443ae44c 3 Jahre her 2,25GB
<none> <none> ad90d7f42416 3 Jahre her 2,25GB
<none> <none> d61ea07d6084 3 Jahre her 2,25GB
<none> <none> d393fd8b4de0 3 Jahre her 2,25GB
discourse/base 2.0.20181031 ea31cd77735a 3 Jahre her 1,88GB
Können Sie versuchen, ./launcher start app auszuführen?