Le vidage du cœur et l’instruction invalide indiquent que quelque chose ne va pas à un niveau bas (CPU, mémoire).
Je ne suis pas un expert en matériel, mais ce CPU est arrivé sur le marché il y a 12 ans et je soupçonne qu’il pourrait être trop ancien (c’est-à-dire qu’il essaie d’exécuter du code compilé qui suppose un CPU plus récent).
Nous y avons réfléchi, mais étant donné que cela fonctionne bien depuis trois ans, qu’est-ce qui aurait été mis à jour dans la pile qui nécessiterait soudainement une instruction plus récente ? (Aussi, quelle instruction ?)
Est-ce que FEATURE: Add support for clear_every parameter in Redis backend (#309) · discourse/message_bus@1baa1ea · GitHub déclencherait un comportement différent dans Redis ? 
Je tiens également à ajouter que vendredi dernier, la mise à niveau majeure de la version s’est déroulée sans problème et qu’elle a fonctionné tout le week-end sans accroc. J’ai même effectué une mise à jour réussie dimanche. Si c’est le CPU, ce qui est compréhensible, qui en est la cause, alors cette erreur se serait manifestée lors de la mise à niveau majeure de la version.
Mais, peut-être y a-t-il eu un changement depuis lundi…
C’est tout à fait possible, il plante dans une routine d’analyse JSON, dans le code du bus de messages, bien que le changement que vous avez mentionné date de plus de 4 mois.
-- Informations de trace 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]
-- Informations de trame de contrôle ----------------------------------------------
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]
Ouais… donc il aurait déjà dû être présent dimanche. 
En examinant les journaux, il semble qu’une autre instance de redis soit déjà en cours d’exécution lorsqu’elle essaie de la démarrer.
Est-ce que cela pourrait être le problème ?
102:C 05 Jul 2022 09:53:34.597 # oO0OoO0OoO0Oo Redis démarre oO0OoO0OoO0Oo
102:C 05 Jul 2022 09:53:34.597 # Version Redis=6.2.6, bits=64, commit=00000000, modifié=0, pid=102, vient de démarrer
102:C 05 Jul 2022 09:53:34.597 # Configuration chargée
102:M 05 Jul 2022 09:53:34.598 * Horloge monotone : POSIX clock_gettime
102:M 05 Jul 2022 09:53:34.599 * Mode d'exécution=standalone, port=6379.
102:M 05 Jul 2022 09:53:34.599 # Serveur initialisé
102:M 05 Jul 2022 09:53:34.599 # ATTENTION overcommit_memory est défini sur 0 ! La sauvegarde en arrière-plan peut échouer en cas de faible mémoire. Pour résoudre ce problème, ajoutez 'vm.overcommit_memory = 1' à /etc/sysctl.conf, puis redémarrez ou exécutez la commande 'sysctl vm.overcommit_memory=1' pour que cela prenne effet.
102:M 05 Jul 2022 09:53:34.599 * Chargement du RDB produit par la version 6.2.6
102:M 05 Jul 2022 09:53:34.599 * Âge du RDB 1972 secondes
102:M 05 Jul 2022 09:53:34.599 * Utilisation de la mémoire du RDB lors de la création 60.60 Mo
102:M 05 Jul 2022 09:53:34.949 # Chargement du RDB terminé, clés chargées : 8005, clés expirées : 9.
102:M 05 Jul 2022 09:53:34.950 * DB chargé depuis le disque : 0.351 secondes
102:M 05 Jul 2022 09:53:34.950 * Prêt à accepter les connexions
129:C 05 Jul 2022 09:53:45.056 # oO0OoO0OoO0Oo Redis démarre oO0OoO0OoO0Oo
129:C 05 Jul 2022 09:53:45.056 # Version Redis=6.2.6, bits=64, commit=00000000, modifié=0, pid=129, vient de démarrer
129:C 05 Jul 2022 09:53:45.056 # Configuration chargée
129:M 05 Jul 2022 09:53:45.057 * Horloge monotone : POSIX clock_gettime
129:M 05 Jul 2022 09:53:45.057 # Avertissement : Impossible de créer le socket d'écoute TCP du serveur *:6379 : bind : Adresse déjà utilisée
129:M 05 Jul 2022 09:53:45.057 # Échec de l'écoute sur le port 6379 (TCP), abandon.
102:gestionnaire-de-signaux (1657015415) SIGTERM reçu, planification de l'arrêt...
102:M 05 Jul 2022 10:03:35.245 # Arrêt demandé par l'utilisateur...
102:M 05 Jul 2022 10:03:35.245 * Sauvegarde du dernier instantané RDB avant la sortie.
102:M 05 Jul 2022 10:03:39.882 * DB sauvegardé sur disque
102:M 05 Jul 2022 10:03:39.882 # Redis est maintenant prêt à quitter, au revoir...
C’est assez normal pour un launcher rebuild app - cela n’affecte rien (pour autant que je sache, du moins…).
Les chemins de code peuvent également se déclencher en fonction de la présence ou de l’absence de certaines données. Peut-être que le code fautif était présent mais qu’il n’était pas exécuté.
Je vais essayer une sorte de bissection sur le dernier ensemble de commits et voir si je peux le réduire à un changement récent spécifique. Cela prendra “un certain temps”… 
Mise à jour :
OK, donc le premier commit défectueux avec l’instruction illégale est Build(deps): Bump oj from 3.13.14 to 3.13.15 (#17309) · discourse/discourse@4c69619 · GitHub qui est lié à Fix NaN object dump issue · ohler55/oj@f0122cf · GitHub
Certains commits précédents échouent également à la compilation, mais avec un problème différent (qui semble également pouvoir être transitoire…) :
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.
Bonne trouvaille, ça plante effectivement dans la gemme oj.
La version 3.13.15 contient également ce commit qui passe à l’utilisation des instructions SSE 4.2 pour des raisons de performance. Et celles-ci ne sont pas prises en charge sur les processeurs AMD Opteron 41xx.
Nous revenons donc à
À mon avis, c’est nul que l’auteur de la gemme ait choisi de faire de cela une décision au moment de la compilation.
Bien. Un changement supplémentaire non mentionné dans le journal des modifications d’oj… 
Donc, si le gem ne fait pas sa compilation native lors de l’installation (nous pourrions donc potentiellement le faire fonctionner via OJ_USE_SSE4_2), il semble qu’il faudra déplacer le serveur… 
Edit : le gem ne distribue aucun objet précompilé, donc cela devrait être réalisable - la question suivante est donc pourquoi il compile avec SSE4.2 sur un système qui ne le prend pas en charge.
Notre image de base actuelle contient la version 3.13.14, elle est donc compilée sur votre système.
Pouvez-vous essayer de reproduire l’erreur avec le script de benchmark du 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;
Vous pouvez également vérifier si elle a été compilée en utilisant l’instruction problématique avec :
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 c’est le cas, c’est probablement quelque chose à signaler au projet du gem oj.
Je veux approfondir un peu plus, mais 1) je veux éviter plus de temps d’arrêt (pour l’instant du moins ; je sais que ce qui précède n’implique pas de temps d’arrêt mais je pourrais être tenté d’essayer d’autres choses) et 2) lorsque cela changera :
pour passer à 3.13.15 et que l’image de base de Discourse hérite de la même exigence minimale de microarchitecture CPU, alors le serveur actuel ne sera de toute façon pas durable (à moins qu’il n’y ait un moyen de contourner cela, comme (ré)installer le gem séparément, par exemple dans le cadre d’un hook pré-code, mais je suppose aussi que c’est un peu compliqué pour la plupart des gens).
Cela soulève également la question de savoir quelle devrait être une date limite raisonnable pour la prise en charge matérielle ; il n’est pas raisonnable d’attendre la prise en charge des CPU 32 bits, donc peut-être que SSE4.2 est un « nouveau minimum » raisonnable pour les logiciels modernes.
En effet, je l’ai déjà signalé en interne.
Salut !
Merci de vous pencher sur ce problème. Je rencontre le même problème sur un Intel Atom N2800 (de fin 2011).
Pensez-vous qu’il existe un moyen de contourner ce problème ou la seule chose que je puisse faire pour l’instant est de migrer vers du matériel plus récent ?
Merci,
Je suis dans une impasse avec mon forum suite à la mise à jour qui m’a été proposée aujourd’hui. Je n’ai vu aucun avertissement concernant la prochaine obsolescence de mes processeurs, et que cela se produise soudainement est… mauvais. Les serveurs disponibles ont tous la même configuration pour des raisons de cohérence, et tous utilisent le même processeur.
AMD Athlon™ II X2 B22 Processor
Il n’est pas pratique d’acheter un nouveau serveur, de le configurer, etc. dans cette économie, même en tenant compte du temps.
Comment puis-je annuler cette mise à jour jusqu’à ce que cette situation soit mieux comprise ? Je ne peux même pas contacter mes utilisateurs pour le moment, le forum étant hors service. Merci.
Si vous utilisez la méthode de déploiement Docker, vous pourriez avoir un ancien conteneur que vous pouvez redémarrer (vérifiez par exemple docker images et/ou docker ps -a).
Vous pouvez également remplacer le commit utilisé pour construire l’instance Discourse en modifiant app.yml et en définissant la version sur le commit précédant le changement, puis en reconstruisant :
params:
version: adb7fa5e2fc51308efc9fc4ee57ecb1c15a85cfa
Discourse échouera à nouveau si vous mettez à jour après cela, ce qui n’est pas idéal étant donné la mise à jour de sécurité qui a été publiée depuis (bien que le potentiel d’exploitation semble assez limité pour la plupart des instances).
Une option (que je n’ai pas encore essayée) consiste à installer la gemme oj séparément et à espérer déclencher la compilation avec les bonnes fonctionnalités du processeur (ou leur absence).
J’avais prévu d’essayer ceci dans app.yml :
hooks:
before_code:
- exec:
cmd:
- gem install oj
mais je n’ai pas la marge de manœuvre pour plus d’interruptions du forum.
Cette mise à jour de sécurité spécifique ne me semble pas pertinente car je ne suis pas dans un environnement d’hébergement partagé. Je ne suis pas sûr de la façon d’interpréter les informations de docker. Voici le ps :
37c258b23221 local_discourse/app « /sbin/boot » il y a 3 mois Sorti (7) il y a 3 heures
Voici la liste des images :
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20220621-0049 a44ca4f67972 3 semaines 2,65 Go
local_discourse/app latest b5f2a8a39709 3 mois 3,53 Go
discourse/base 2.0.20220413-0411 ab71a5d97460 3 mois 2,81 Go
<none> <none> 58ba7d1c8d7a 3 mois 3,74 Go
discourse/base 2.0.20220224-2005 cd112601450a 4 mois 2,84 Go
<none> <none> d9cf1feb92fd 6 mois 3,19 Go
<none> <none> d53ee33f6fe1 6 mois 3,19 Go
<none> <none> 14f79500c49c 6 mois 3,19 Go
<none> <none> edff9b614f46 6 mois 3,19 Go
<none> <none> e2348b41f937 6 mois 3,19 Go
<none> <none> 42f6511b414c 6 mois 3,19 Go
<none> <none> 3086f92af2fe 6 mois 3,19 Go
<none> <none> 6ada029723ba 6 mois 3,19 Go
<none> <none> ca61149580d4 6 mois 3,19 Go
<none> <none> ce5ae3bb62ac 6 mois 3,19 Go
<none> <none> e9a5c1b1aed4 6 mois 3,19 Go
<none> <none> 6bb94ce1e01f 6 mois 3,19 Go
<none> <none> e1df4acbd927 6 mois 3,19 Go
<none> <none> 7e05a0b160c5 6 mois 3,19 Go
<none> <none> 979926f28a73 6 mois 3,19 Go
<none> <none> d055f9b01556 6 mois 3,19 Go
<none> <none> aa0c779093dc 6 mois 3,19 Go
discourse/base 2.0.20211118-0105 b6cc7cf8974a 7 mois 2,58 Go
discourse/base 2.0.20210528-1735 482386bf57af 13 mois 2,36 Go
<none> <none> e6011d2b206c 14 mois 2,69 Go
discourse/base 2.0.20210415-1332 30e4746e631e 15 mois 2,23 Go
<none> <none> 8066ac13b8c3 17 mois 2,45 Go
discourse/base 2.0.20201221-2020 c0704d4ce2b4 18 mois 2,11 Go
<none> <none> 043da6b3335d 2 ans 2,4 Go
discourse/base 2.0.20200429-2110 dc919e1dae2c 2 ans 2,13 Go
<none> <none> ff15472f4794 2 ans 2,79 Go
discourse/base 2.0.20191013-2320 09725007dc9e 2 ans 2,3 Go
<none> <none> f65391a062f0 2 ans 2,62 Go
discourse/base 2.0.20190901-2315 10f636afbeaf 2 ans 2,29 Go
<none> <none> 6944d06786b4 2 ans 2,31 Go
discourse/base 2.0.20190625-0946 2b3a5b47565f 3 ans 1,93 Go
<none> <none> 60b39deba7d2 3 ans 2,3 Go
discourse/base 2.0.20190505-2322 ed87227f60d2 3 ans 1,91 Go
<none> <none> cc5c0e56298c 3 ans 2,38 Go
discourse/base 2.0.20190321-0122 7db99586b5b5 3 ans 1,97 Go
<none> <none> b19f9a483788 3 ans 2,27 Go
discourse/base 2.0.20190217 9c24db193c37 3 ans 1,92 Go
hello-world latest fce289e99eb9 3 ans 1,84 Ko
<none> <none> 614db6988e9c 3 ans 2,25 Go
<none> <none> 729b196da862 3 ans 2,25 Go
<none> <none> 80584ec5ec01 3 ans 2,25 Go
<none> <none> 0e2481aefed8 3 ans 2,25 Go
<none> <none> 725d0c17a6bb 3 ans 2,25 Go
<none> <none> 220bed95d236 3 ans 2,25 Go
<none> <none> fca469dba597 3 ans 2,25 Go
<none> <none> edab31d0ffce 3 ans 2,25 Go
<none> <none> dbacaff2d35e 3 ans 2,25 Go
<none> <none> 3d6a0453da1d 3 ans 2,25 Go
<none> <none> fbf0529eb303 3 ans 2,25 Go
<none> <none> 7a45443ae44c 3 ans 2,25 Go
<none> <none> ad90d7f42416 3 ans 2,25 Go
<none> <none> d61ea07d6084 3 ans 2,25 Go
<none> <none> d393fd8b4de0 3 ans 2,25 Go
discourse/base 2.0.20181031 ea31cd77735a 3 ans 1,88 Go
Pouvez-vous essayer un ./launcher start app ?