يشير تفريغ النواة والتعليمات غير الصالحة إلى وجود خطأ على مستوى منخفض (وحدة المعالجة المركزية، الذاكرة).
أنا لست خبيرًا في الأجهزة، لكن وحدة المعالجة المركزية هذه طرحت في السوق قبل 12 عامًا وأشك في أنها قد تكون قديمة جدًا (أي أنها تحاول تشغيل تعليمات برمجية مجمعة تفترض وجود وحدة معالجة مركزية أحدث).
لقد فكرنا في هذا، ولكن نظرًا لأنه كان يعمل بشكل جيد خلال السنوات الثلاث الماضية، فما الذي تم تحديثه ضمن المكدس والذي يتطلب فجأة تعليمات جديدة؟ (أيضًا، ما هي التعليمات؟)
هل FEATURE: Add support for clear_every parameter in Redis backend (#309) · discourse/message_bus@1baa1ea · GitHub يؤدي إلى سلوك مختلف داخل Redis؟ 
أريد أيضًا أن أضيف أنه يوم الجمعة الماضي تم إجراء ترقية الإصدار الرئيسي بسلاسة وعملت طوال عطلة نهاية الأسبوع دون أي مشاكل. لقد أجريت حتى تحديثًا ناجحًا يوم الأحد. إذا كان السبب هو وحدة المعالجة المركزية (CPU)، وهو أمر مفهوم، لكان قد أظهر هذا الخطأ مع ترقية الإصدار الرئيسي.
ولكن، ربما كان هناك تغيير منذ يوم الاثنين…
قد يكون هذا صحيحًا جدًا، فهو يتعطل في روتين تحليل JSON، في كود ناقل الرسائل، على الرغم من أن التغيير الذي ذكرته قديم بأكثر من 4 أشهر.
-- C level backtrace information -------------------------------------------
/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 information -----------------------------------------------
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]
نعم… لذا كان يجب أن يكون موجودًا بالفعل يوم الأحد. 
بالنظر إلى السجلات، يبدو أن هناك بالفعل مثيلًا آخر لـ redis قيد التشغيل عندما يحاول بدء تشغيله.
هل يمكن أن يكون هذا هو السبب؟
102:C 05 Jul 2022 09:53:34.597 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
102:C 05 Jul 2022 09:53:34.597 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=102, just started
102:C 05 Jul 2022 09:53:34.597 # Configuration loaded
102:M 05 Jul 2022 09:53:34.598 * monotonic clock: POSIX clock_gettime
102:M 05 Jul 2022 09:53:34.599 * Running mode=standalone, port=6379.
102:M 05 Jul 2022 09:53:34.599 # Server initialized
102:M 05 Jul 2022 09:53:34.599 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
102:M 05 Jul 2022 09:53:34.599 * Loading RDB produced by version 6.2.6
102:M 05 Jul 2022 09:53:34.599 * RDB age 1972 seconds
102:M 05 Jul 2022 09:53:34.599 * RDB memory usage when created 60.60 Mb
102:M 05 Jul 2022 09:53:34.949 # Done loading RDB, keys loaded: 8005, keys expired: 9.
102:M 05 Jul 2022 09:53:34.950 * DB loaded from disk: 0.351 seconds
102:M 05 Jul 2022 09:53:34.950 * Ready to accept connections
129:C 05 Jul 2022 09:53:45.056 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
129:C 05 Jul 2022 09:53:45.056 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=129, just started
129:C 05 Jul 2022 09:53:45.056 # Configuration loaded
129:M 05 Jul 2022 09:53:45.057 * monotonic clock: POSIX clock_gettime
129:M 05 Jul 2022 09:53:45.057 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
129:M 05 Jul 2022 09:53:45.057 # Failed listening on port 6379 (TCP), aborting.
102:signal-handler (1657015415) Received SIGTERM scheduling shutdown...
102:M 05 Jul 2022 10:03:35.245 # User requested shutdown...
102:M 05 Jul 2022 10:03:35.245 * Saving the final RDB snapshot before exiting.
102:M 05 Jul 2022 10:03:39.882 * DB saved on disk
102:M 05 Jul 2022 10:03:39.882 # Redis is now ready to exit, bye bye...
هذا أمر طبيعي جدًا بالنسبة لتطبيق launcher rebuild app - فهو لا يؤثر على أي شيء (على حد علمي، على الأقل…).
يمكن لمسارات التعليمات البرمجية أيضًا أن تؤدي إلى تشغيلها بناءً على وجود بيانات معينة أو عدم وجودها. ربما كان الكود المخالف موجودًا ولكنه لم يكن قيد التنفيذ.
سأجرب بعض التقسيم شبه الثنائي على أحدث مجموعة من الالتزامات وأرى ما إذا كان بإمكاني تضييقها إلى تغيير حديث محدد. سيستغرق هذا “بعض الوقت”… 
تعديل:
حسنًا، أول التزام سيء مع التعليمات غير القانونية هو Build(deps): Bump oj from 3.13.14 to 3.13.15 (#17309) · discourse/discourse@4c69619 · GitHub والذي يرتبط بـ Fix NaN object dump issue · ohler55/oj@f0122cf · GitHub
بعض الالتزامات السابقة تفشل أيضًا في البناء ولكن مع مشكلة مختلفة (والتي تبدو أيضًا وكأنها قد تكون عابرة…):
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.
اكتشاف جيد، إنه بالفعل يتعطل في oj gem.
الإصدار 3.13.15 يحتوي أيضًا على هذا الالتزام الذي يتحول إلى استخدام تعليمات SSE 4.2 للأداء. وهذه غير مدعومة على معالجات AMD Opteron 41xx.
لذا عدنا إلى
في رأيي، من السيء أن مؤلف الـ gem اختار جعل هذا قرارًا وقت الترجمة.
جميل. تغيير إضافي لم يُذكر في سجل تغييرات oj… 
إذًا، إذا لم تقم الـ gem بتجميعها الأصلي أثناء التثبيت (مما قد يدفعنا إلى جعلها تعمل عبر OJ_USE_SSE4_2)، فستحتاج إلى نقل الخادم… 
تعديل: الـ gem لا توزع أي كائنات مجمعة مسبقًا، لذا يجب أن يكون هذا قابلاً للتطبيق - لذا السؤال التالي هو لماذا يتم تجميعها باستخدام SSE4.2 على نظام لا يدعمها.
صورة الأساس الحالية لدينا تشحن الإصدار 3.13.14، لذلك يتم تجميعها على نظامك.
هل يمكنك محاولة إعادة إنتاج الخطأ باستخدام نص القياس من الالتزام:
○ → 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;
يمكنك أيضًا التحقق مما إذا كان قد تم تجميعه باستخدام التعليمات الإشكالية مع:
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
إذا كان الأمر كذلك، فمن المحتمل أن يكون هذا شيئًا يجب الإبلاغ عنه لمشروع gem الخاص بـ oj.
أريد أن أبحث في هذا الأمر أكثر، ولكن 1) أريد تجنب المزيد من التوقف (لفترة على الأقل؛ أعلم أن ما ورد أعلاه لا ينطوي على توقف، ولكن قد أغريني بتجربة أشياء أخرى) و 2) عندما يتغير هذا:
[اقتباس=“Michael Brown, post:33, topic:231862, username:supermathie”]
تشحن صورتنا الأساسية الحالية 3.13.14
[/اقتباس]
إلى 3.13.15 وتكتسب صورة Discourse الأساسية نفس الحد الأدنى من متطلبات المعمارية الدقيقة لوحدة المعالجة المركزية (CPU)، فلن يكون الخادم الحالي مستدامًا على أي حال (إلا إذا كانت هناك طريقة للتحايل على ذلك، مثل (إعادة) تثبيت الجوهرة بشكل منفصل على سبيل المثال كجزء من خطاف ما قبل الكود، ولكنني أعتقد أيضًا أن هذا يمثل مشكلة لمعظم الناس).
كما أنه يثير مسألة ما هو تاريخ انتهاء الدعم المعقول للأجهزة على أي حال؛ ليس من المعقول توقع دعم وحدة المعالجة المركزية (CPU) ذات 32 بت، لذلك ربما يكون SSE4.2 هو “الحد الأدنى الجديد” المعقول للبرامج الحديثة.
بالفعل، لقد أثرت هذا داخليًا بالفعل.
أهلاً!
شكراً لك على التحقيق في هذا الأمر. أواجه نفس المشكلة على جهاز Intel Atom N2800 (من نهاية عام 2011).
هل تعتقد أنه قد يكون هناك حل لهذه المشكلة أم أن كل ما يمكنني فعله في الوقت الحالي هو الترقية إلى جهاز أحدث؟
شكراً لك،
أنا في ورطة الآن مع منتداي بسبب التحديث الذي طُلب مني القيام به اليوم. لم أرَ أي تحذيرات بشأن إيقاف دعم أي وحدات معالجة مركزية قادمة، وأن يحدث هذا فجأة هو أمر… سيء. الخوادم المتاحة كلها بنفس التكوين للاتساق، وجميعها تستخدم نفس وحدة المعالجة المركزية.
معالج AMD Athlon™ II X2 B22
ليس من العملي الخروج وشراء خادم جديد، وتكوينه، وما إلى ذلك في هذا الوضع الاقتصادي، حتى مع الأخذ في الاعتبار الوقت.
كيف يمكنني التراجع عن هذا التحديث حتى يتم فهم هذا الموقف بشكل أفضل؟ لا يمكنني حتى الاتصال بمستخدمي الآن والمنتدى معطل. شكراً.
إذا كنت تستخدم طريقة نشر Docker، فقد يكون لديك حاوية قديمة يمكنك إعادة تشغيلها (تحقق على سبيل المثال من docker images و/أو docker ps -a).
يمكنك أيضًا تجاوز الـ commit المستخدم لبناء نسخة Discourse عن طريق تعديل app.yml وتعيين الإصدار إلى الـ commit السابق للتغيير، ثم إعادة البناء:
params:
version: adb7fa5e2fc51308efc9fc4ee57ecb1c15a85cfa
سيتعطل Discourse مرة أخرى إذا قمت بالتحديث بعد ذلك، وهذا ليس مثاليًا نظرًا لـ تحديث الأمان الذي تم إصداره منذ ذلك الحين (على الرغم من أن احتمالية الاستغلال تبدو محدودة جدًا لمعظم النسخ).
أحد الخيارات (الذي لم أجربه بعد) هو تثبيت gem oj بشكل منفصل ونأمل في تشغيل التجميع باستخدام ميزات وحدة المعالجة المركزية الصحيحة (أو عدم وجودها).
كنت أخطط لتجربة هذا في app.yml:
hooks:
before_code:
- exec:
cmd:
- gem install oj
لكن ليس لدي متسع لمزيد من تعطل المنتدى.
تحديث الأمان هذا لا يبدو ذا صلة بي لأنني لست في بيئة استضافة مشتركة. لست متأكدًا من كيفية تفسير معلومات Docker. إليك ps:
37c258b23221 local_discourse/app " /sbin/boot " قبل 3 أشهر خرج (7) قبل 3 ساعات
إليك قائمة الصور:
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20220621-0049 a44ca4f67972 قبل 3 أسابيع 2.65GB
local_discourse/app latest b5f2a8a39709 قبل 3 أشهر 3.53GB
discourse/base 2.0.20220413-0411 ab71a5d97460 قبل 3 أشهر 2.81GB
<none> <none> 58ba7d1c8d7a قبل 3 أشهر 3.74GB
discourse/base 2.0.20220224-2005 cd112601450a قبل 4 أشهر 2.84GB
<none> <none> d9cf1feb92fd قبل 6 أشهر 3.19GB
<none> <none> d53ee33f6fe1 قبل 6 أشهر 3.19GB
<none> <none> 14f79500c49c قبل 6 أشهر 3.19GB
<none> <none> edff9b614f46 قبل 6 أشهر 3.19GB
<none> <none> e2348b41f937 قبل 6 أشهر 3.19GB
<none> <none> 42f6511b414c قبل 6 أشهر 3.19GB
<none> <none> 3086f92af2fe قبل 6 أشهر 3.19GB
<none> <none> 6ada029723ba قبل 6 أشهر 3.19GB
<none> <none> ca61149580d4 قبل 6 أشهر 3.19GB
<none> <none> ce5ae3bb62ac قبل 6 أشهر 3.19GB
<none> <none> e9a5c1b1aed4 قبل 6 أشهر 3.19GB
<none> <none> 6bb94ce1e01f قبل 6 أشهر 3.19GB
<none> <none> e1df4acbd927 قبل 6 أشهر 3.19GB
<none> <none> 7e05a0b160c5 قبل 6 أشهر 3.19GB
<none> <none> 979926f28a73 قبل 6 أشهر 3.19GB
<none> <none> d055f9b01556 قبل 6 أشهر 3.19GB
<none> <none> aa0c779093dc قبل 6 أشهر 3.19GB
discourse/base 2.0.20211118-0105 b6cc7cf8974a قبل 7 أشهر 2.58GB
discourse/base 2.0.20210528-1735 482386bf57af قبل 13 شهرًا 2.36GB
<none> <none> e6011d2b206c قبل 14 شهرًا 2.69GB
discourse/base 2.0.20210415-1332 30e4746e631e قبل 15 شهرًا 2.23GB
<none> <none> 8066ac13b8c3 قبل 17 شهرًا 2.45GB
discourse/base 2.0.20201221-2020 c0704d4ce2b4 قبل 18 شهرًا 2.11GB
<none> <none> 043da6b3335d قبل عامين 2.4GB
discourse/base 2.0.20200429-2110 dc919e1dae2c قبل عامين 2.13GB
<none> <none> ff15472f4794 قبل عامين 2.79GB
discourse/base 2.0.20191013-2320 09725007dc9e قبل عامين 2.3GB
<none> <none> f65391a062f0 قبل عامين 2.62GB
discourse/base 2.0.20190901-2315 10f636afbeaf قبل عامين 2.29GB
<none> <none> 6944d06786b4 قبل عامين 2.31GB
discourse/base 2.0.20190625-0946 2b3a5b47565f قبل 3 سنوات 1.93GB
<none> <none> 60b39deba7d2 قبل 3 سنوات 2.3GB
discourse/base 2.0.20190505-2322 ed87227f60d2 قبل 3 سنوات 1.91GB
<none> <none> cc5c0e56298c قبل 3 سنوات 2.38GB
discourse/base 2.0.20190321-0122 7db99586b5b5 قبل 3 سنوات 1.97GB
<none> <none> b19f9a483788 قبل 3 سنوات 2.27GB
discourse/base 2.0.20190217 9c24db193c37 قبل 3 سنوات 1.92GB
hello-world latest fce289e99eb9 قبل 3 سنوات 1.84kB
<none> <none> 614db6988e9c قبل 3 سنوات 2.25GB
<none> <none> 729b196da862 قبل 3 سنوات 2.25GB
<none> <none> 80584ec5ec01 قبل 3 سنوات 2.25GB
<none> <none> 0e2481aefed8 قبل 3 سنوات 2.25GB
<none> <none> 725d0c17a6bb قبل 3 سنوات 2.25GB
<none> <none> 220bed95d236 قبل 3 سنوات 2.25GB
<none> <none> fca469dba597 قبل 3 سنوات 2.25GB
<none> <none> edab31d0ffce قبل 3 سنوات 2.25GB
<none> <none> dbacaff2d35e قبل 3 سنوات 2.25GB
<none> <none> 3d6a0453da1d قبل 3 سنوات 2.25GB
<none> <none> fbf0529eb303 قبل 3 سنوات 2.25GB
<none> <none> 7a45443ae44c قبل 3 سنوات 2.25GB
<none> <none> ad90d7f42416 قبل 3 سنوات 2.25GB
<none> <none> d61ea07d6084 قبل 3 سنوات 2.25GB
<none> <none> d393fd8b4de0 قبل 3 سنوات 2.25GB
discourse/base 2.0.20181031 ea31cd77735a قبل 3 سنوات 1.88GB
هل يمكنك تجربة ./launcher start app؟