بعد تثبيت Discourse باستخدام “Docker version 20.10.5, build 55c4c8” على نظام CentOS 8، يعمل الموقع، لكنه يتعطل دائمًا عند استدعاءات DELETE إلى /draft.json.
أنا أعمل مع Apache، وقد جربت كلًا من وكيل العكسي (reverse proxy) الخاص بـ Apache وHAProxy، لكن السلوك هو نفسه.
لا أعرف ما إذا كان هناك أي ارتباط، لكنني أجد العديد من هذه الأخطاء في ملف unicorn.stdout.log:
==> ./shared/standalone/log/rails/unicorn.stdout.log <==
2021-03-18T10:02:25.138Z pid=108 tid=ocs ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 119
2021-03-18T10:40:09.682Z pid=119 tid=orn ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.684Z pid=119 tid=ohf ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.685Z pid=119 tid=owv ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=oob ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=omr ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 121
53:M 18 Mar 2021 17:07:05.076 * 10 تغييرات خلال 300 ثانية. جاري الحفظ...
53:M 18 Mar 2021 17:07:05.076 * بدأت عملية الحفظ في الخلفية بواسطة المعرف 25018
25018:C 18 Mar 2021 17:07:05.126 * تم حفظ قاعدة البيانات على القرص
25018:C 18 Mar 2021 17:07:05.127 * RDB: تم استخدام 2 ميجابايت من الذاكرة عبر النسخ عند الكتابة
53:M 18 Mar 2021 17:07:05.177 * انتهت عملية الحفظ في الخلفية بنجاح
53:M 18 Mar 2021 17:12:06.097 * 10 تغييرات خلال 300 ثانية. جاري الحفظ...
53:M 18 Mar 2021 17:12:06.098 * بدأت عملية الحفظ في الخلفية بواسطة المعرف 25337
25337:C 18 Mar 2021 17:12:06.145 * تم حفظ قاعدة البيانات على القرص
25337:C 18 Mar 2021 17:12:06.145 * RDB: تم استخدام 2 ميجابايت من الذاكرة عبر النسخ عند الكتابة
53:M 18 Mar 2021 17:12:06.198 * انتهت عملية الحفظ في الخلفية بنجاح
جزء من سجل Haproxy يحتوي على أخطاء 408 عند استخدام HTTP DELETE، ما الذي قد يكون “يسقط” طلبات الحذف @codinghorror؟ إذا وصلت طلبات DELETE إلى Haproxy، فيجب أن تصل أيضًا إلى البرنامج داخل Docker، فهل يمكن أن يكون هناك شيء هناك “مسؤول” عن المشكلة؟
هذا هو production.log، لم أرَ أبدًا طلب حذف يظهر، لكنني أرى كل شيء آخر مسجلاً (فتح موضوع، تعديل، حفظ، إلخ):
Completed 200 OK in 81ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 14861)
Started GET "/composer_messages?composer_action=edit&topic_id=10&post_id=13" for 176.243.226.205 at 2021-03-20 15:51:09 +0100
Processing by ComposerMessagesController#index as JSON
Parameters: {"composer_action"=>"edit", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 1191ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 16940)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:14 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 9ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 3192)
Started PUT "/t/e-previsto-un-ritorno-di-freddo-nutro/10" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by TopicsController#update as */*
Parameters: {"title"=>"E' previsto un ritorno di freddo, nutro?", "category_id"=>1, "slug"=>"e-previsto-un-ritorno-di-freddo-nutro", "topic_id"=>"10", "topic"=>{"title"=>"E' previsto un ritorno di freddo, nutro?", "category_id"=>1}}
Completed 200 OK in 19ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 5149)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"closed", "topic_id"=>"10"}
Completed 200 OK in 10ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 3159)
Started PUT "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by PostsController#update as */*
Parameters: {"post"=>{"edit_reason"=>"", "cooked"=>"<p>post di test per vedere. ssss</p>", "raw"=>"post di test per vedere. ssss", "topic_id"=>"10", "raw_old"=>""}, "id"=>"13"}
Completed 200 OK in 3296ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 86638)
Started GET "/t/10.json" for 176.243.226.205 at 2021-03-20 15:51:20 +0100
Processing by TopicsController#show as JSON
Parameters: {"id"=>"10"}
Completed 200 OK in 143ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 52707)
Started GET "/draft.json?draft_key=topic_10" for 176.243.226.205 at 2021-03-20 15:51:27 +0100
Processing by DraftController#show as JSON
Parameters: {"draft_key"=>"topic_10"}
Completed 200 OK in 38ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 4317)
Started GET "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:27 +0100
Processing by PostsController#show as JSON
Parameters: {"id"=>"13"}
Completed 200 OK in 16ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 5026)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:29 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 20ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3304)
Started GET "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:38 +0100
Processing by PostsController#show as JSON
Parameters: {"id"=>"13"}
Completed 200 OK in 121ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 56890)
هذا يعني أن وكيل العكس الخاص بك مُعد بشكل خاطئ ويقوم بإسقاط الطلبات غير GET/POST. هذه مشكلة شائعة جدًا، وهي أحد الأسباب التي تجعلنا نوفر وكيل عكسي مُعد مسبقًا داخل الحاوية حتى لا يحتاج الناس إلى التعديل على ذلك.
إذا قمت بإزالة HAProxy والسماذ للحاوية نفسها بالاستماع على المنفذ 80/443، فهل لا تزال المشكلة تحدث؟
تأكد من نجاح أمر `gem install libv8 -v '8.4.255.0' --source 'https://rubygems.org/'` قبل التجميع (bundling).
في ملف Gemfile:
تم حل mini_racer إلى الإصدار 0.3.1، الذي يعتمد على
libv8
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:220:in `handle_error'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:102:in `call'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:71:in `call'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:270:in `install_in_parallel'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:210:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:90:in `block in run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:12:in `block in lock'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `open'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `lock'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:72:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:24:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli/install.rb:64:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:259:in `block in install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/settings.rb:115:in `temporary'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:258:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:49:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:37:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
I, [2021-03-20T23:42:40.998961 #1] INFO -- : إنهاء العمليات غير المتزامنة
I, [2021-03-20T23:42:40.998991 #1] INFO -- : إرسال إشارة INT إلى HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 66
I, [2021-03-20T23:42:40.999030 #1] INFO -- : إرسال إشارة TERM إلى exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 183
2021-03-20 23:42:40.999 UTC [66] LOG: تم استلام طلب إيقاف سريع
183:signal-handler (1616283760) تم استلام إشارة SIGTERM وجدولة الإيقاف...
2021-03-20 23:42:41.013 UTC [66] LOG: إلغاء أي معاملات نشطة
2021-03-20 23:42:41.014 UTC [66] LOG: خرج العامل الخلفي "logical replication launcher" (معرف العملية 75) مع رمز خروج 1
2021-03-20 23:42:41.016 UTC [70] LOG: جاري الإغلاق
183:M 20 Mar 2021 23:42:41.058 # تم طلب الإيقاف من قبل المستخدم...
183:M 20 Mar 2021 23:42:41.058 * حفظ لقطة RDB النهائية قبل الخروج.
183:M 20 Mar 2021 23:42:41.061 * تم حفظ قاعدة البيانات على القرص
183:M 20 Mar 2021 23:42:41.061 # أصبح Redis جاهزًا للخروج، وداعًا...
2021-03-20 23:42:41.263 UTC [66] LOG: تم إيقاف نظام قاعدة البيانات
فشل
--------------------
خطأ Pups::ExecError: فشل الأمر cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' مع رمز عودة #<Process::Status: pid 348 exit 5>
موقع الفشل: /pups/lib/pups/exec_command.rb:112:in `spawn'
فشل التنفيذ مع المعلمات {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}
9b0ca932a7dd52ccdd11e268910e3edcd8369c0c08f65e7f8686d542b9be473b
** فشل التمهيد ** يرجى التمرير للأعلى والبحث عن رسائل الخطأ السابقة، فقد يكون هناك أكثر من خطأ.
قد يساعد ./discourse-doctor في تشخيص المشكلة.
➜ discourse git:(master) ✗
@Falco حاولت إعداد الإعداد الرسمي مرة أخرى ولكن باستخدام “tests-passed” بدلاً من stable، ولم يظهر خطأ مكتبة mini_racer، لكنني ما زلت أواجه مشكلة الحذف (DELETE)، كما هو موضح في الفيديو الذي يعرض تتبع سجل nginx والمتصفح مع فتح وحدة التحكم.
تظهر طلبات POST فورًا في سجل nginx، بينما تظهر طلبات DELETE فقط بعد حدوث خطأ، وهو أمر غريب.
أرى ذلك. بما أن المشكلة لا يمكن إعادة إنتاجها في تثبيت جديد، فأنا أقترح إغلاق هذا الموضوع. إذا تكررت المشكلة، يرجى فتح موضوع جديد يتضمن خطوات إعادة الإنتاج.
أمر Curl يعطي خطأ CSRF، ويظهر فورًا في سجلات nginx الداخلية لـ Discourse، لكن الحذف من الواجهة لا يعمل ويظهر في السجل متأخرًا بحوالي 35 ثانية كما في الفيديو الذي أرسلته.
إذا وضعت discourse.apicolturaitalianafb.it:8880 كاسم المضيف في ملف app.yml، وأعدت البناء ثم ذهبت إلى http://discourse.apicolturaitalianafb.it:8880، فإنه يعمل بشكل طبيعي، لكنني لا أستطيع استخدامه بهذه الطريقة.
بما أن Apache يعمل كموقع إنتاجي، جربت وضعه خلف haproxy وفقًا للوثائق في هذا الموقع، فتوقف حذف الرسائل من Discourse عن العمل، بينما يعمل أمر curl الخاص بك. جربت أيضًا الوكيل العكسي لـ Apache، فيعمل أمر curl لكن الحذف من Discourse لا يعمل. جربت أيضًا إعداد Discourse للعمل عبر منفذ Unix ثم الوكيل العكسي إليه، لكن المشكلة نفسها.
بالنسبة لي، الدليل هو أن الوكيل العكسي لا “يوقف” عمليات الحذف، بل أن سكريبتات JavaScript في Discourse تتوقف لسبب ما عن تنفيذ حذف HTML بشكل صحيح.
.