فشل اختبار نبض Sidekiq، جاري إعادة التشغيل

الدعم تثبيت
1

مرحبًا! لقد وجدت خطأً غريبًا في صفحة المسؤول، حيث أن sidekiq لا يعمل.
افتحت السجلات ووجدت مئات الأخطاء مثل:

/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:112:in `report_to_store'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:103:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:54:in `add'
/usr/local/lib/ruby/2.6.0/logger.rb:534:in `warn'
config/unicorn.conf.rb:147:in `check_sidekiq_heartbeat'
config/unicorn.conf.rb:164:in `master_sleep'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/lib/unicorn/http_server.rb:296:in `join'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'

وهذه الأخطاء من التطبيق:

run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
run-parts: executing /etc/runit/1.d/letsencrypt
[Wed 01 Jan 2020 10:40:41 AM UTC] Domains not changed.
[Wed 01 Jan 2020 10:40:41 AM UTC] Skip, Next renewal time is: Tue Feb 25 00:52:11 UTC 2020
[Wed 01 Jan 2020 10:40:41 AM UTC] Add '--force' to force to renew.
[Wed 01 Jan 2020 10:40:41 AM UTC] Installing key to:/shared/ssl/discourse.example.com.key
[Wed 01 Jan 2020 10:40:41 AM UTC] Installing full chain to:/shared/ssl/discourse.example.com.cer
[Wed 01 Jan 2020 10:40:41 AM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Wed 01 Jan 2020 10:40:41 AM UTC] Reload error for :
[Wed 01 Jan 2020 10:40:42 AM UTC] Domains not changed.
[Wed 01 Jan 2020 10:40:42 AM UTC] Skip, Next renewal time is: Wed Jan  8 00:39:10 UTC 2020
[Wed 01 Jan 2020 10:40:42 AM UTC] Add '--force' to force to renew.
[Wed 01 Jan 2020 10:40:42 AM UTC] Installing key to:/shared/ssl/discourse.example.com_ecc.key
[Wed 01 Jan 2020 10:40:42 AM UTC] Installing full chain to:/shared/ssl/discourse.example.com_ecc.cer
[Wed 01 Jan 2020 10:40:42 AM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Wed 01 Jan 2020 10:40:42 AM UTC] Reload error for :
Started runsvdir, PID is 628
chgrp: invalid group: 'syslog'
rsyslogd: imklog: cannot open kernel log (/proc/kmsg): Operation not permitted.
rsyslogd: activation of module imklog failed [v8.1901.0 try https://www.rsyslog.com/e/2145 ]
supervisor pid: 633 unicorn pid: 647

لقد حاولت تفريغ قاعدة بيانات Redis، لكن ذلك لم يساعد.
لدي حاويات منفصلة للتطبيق وPostgres وRedis.
هل لديك أي أفكار حول كيفية إصلاح هذا؟

2

هل تم إيقاف Sidekiq مؤقتًا؟ هل تزداد عدد الوظائف في قائمة الانتظار؟

3

يُظهر وجود عمليتين في طابور الافتراضي، وكلاهما من نوع Jobs::VersionCheck.
بعد تفريغ قاعدة بيانات Redis، يُظهر 0 عملية مكتملة، و0 فاشلة، و2 في الانتظار.

تُظهر صفحة الجدولة أن بعض العمليات في طابور الانتظار أو قيد التنفيذ، لكن هذه العمليات لا تُحسب في إحصائيات صفحة Sidekiq. جميع العمليات في صفحة الجدولة لها مدة زمنية فارغة أو -1 مللي ثانية.

لذا، الأرقام لا تتراكم، ولا يتغير شيء حرفيًا.
كيف يمكن التحقق مما إذا كان Sidekiq متوقفًا مؤقتًا؟

4

نفس المشكلة هنا مع آخر تحديث، لا توجد تغييرات سوى التحديث عبر إعادة البناء، لوحة الإدارة تقول إن Sidekiq لا يعمل. لدي PostgreSQL و Redis في حاوية واحدة والتطبيق في حاوية أخرى، وقمت بإعادة تشغيلهم جميعًا مرة أخرى. الطوابير تحتوي على بضع مئات من العناصر، لكن لا شيء يتم معالجته.

تحرير 1: مسح جميع الطوابير لم يحل المشكلة أو يساعد في شيء، إنها تمتلئ مرة أخرى ولا تزال لا تتم معالجتها.

تحرير 2: وأعدت بناء المنتدى مع كل وقت التوقف الذي يتطلبه ذلك، وما زلت أرى هذه الرسالة:

image
image1084×160 14.4 KB

وطوابير Sidekiq لا تعمل في /sidekiq. كان كل هذا يعمل دون أي مشكلة قبل التحديث إلى الإصدار 2.4.0.beta9 من beta7.

تحرير 3: أكثر من 50 جيجابايت من المساحة الحرة. يعمل النسخ الاحتياطي اليدوي (أقل بقليل من 300 ميجابايت) بنجاح، ويذكر أنه يوقف Sidekiq ثم يعيد تشغيله دون الإبلاغ عن أي خطأ في السجل، لكن يبدو أن Sidekiq لا يزال لا يعمل؟

تحرير 4: السجل الوحيد الملحوظ في /logs هو “فشل اختبار نبض Sidekiq، جاري إعادة التشغيل” الذي يتكرر باستمرار.

تحرير 5: يبدو أن Redis يعمل بشكل جيد، على الأقل ملف السجل الخاص به مشغول بالقول إنه لا يوجد لديه الكثير للقيام به… وللتوضيح:

[3] pry(main)> Sidekiq.paused?
=> false

تحرير 6: قمت بمسح الطوابير منذ فترة، عدت إلى 10 مهام معلقة في الطابور ولكن لا تتم معالجتها.

تحرير 7: اكتشفت أن الأمر bundle exec sidekiq هو الطريقة المعتادة لبدء Sidekiq في مشروع عادي، لذا دعنا نجرب تشغيله لنرى ماذا يحدث:

root@vps198273-forum:/var/www/discourse# bundle exec sidekiq
2020-01-06T05:10:18.814Z pid=31242 tid=gn383wxbu INFO: Booting Sidekiq 6.0.4 with redis options {:host=>"forum-data", :port=>6379, :namespace=>"sidekiq", :id=>"Sidekiq-server-PID-31242", :url=>nil}
You are connecting to Redis v3.0.6, Sidekiq requires Redis v4.0.0 or greater
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/lib/sidekiq/cli.rb:62:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/bin/sidekiq:12:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/lib/sidekiq/cli.rb:62:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/bin/sidekiq:12:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'

You are connecting to Redis v3.0.6, Sidekiq requires Redis v4.0.0 or greater

حسنًا، هذا يبدو مثيرًا للاهتمام؟ دعنا نجرب إعادة بناء حاوية البيانات والصلاة من رعب لمس البيانات، ههه…

تحرير 8: حسنًا، يبدو أنه يعمل بـ Redis 5.0.5 (لماذا لا يُستخدم PostgreSQL pubsub لهذا الغرض؟)، وهو بالتأكيد 4.0.0 أو أحدث… وقد انتهى إعادة البناء، جربنا المنتدى، تبدو بياناته لا تزال موجودة، ولدينا ارتفاع!

image
image367×572 61.8 KB

يبدو أنه تم الإصلاح! ربما يكون هذا المنشور مفيدًا لشخص ما. أتمنى أن يكون المنتدى قد أعطاني خطأ Sidekiq حول إصدار Redis قديم، لكنني أظن أن هذه السجلات تذهب إلى الهاوية في مكان ما لأنني لم أرَها في أي مكان. ^.^

5

هذا عمل تحقيقي ممتاز، وآمل أن يفيد الآخرين.

6

كيف حصلت على نسخة قديمة من Redis؟ هل تستخدم تثبيتًا غير قياسي؟

7

أستخدم إعدادًا متعدد الحاويات ولم أعد بناء Redis أبدًا.
سأحاول إعادة بناء Redis.

تحديث:
@OvermindDL1، شكرًا لك على الحلول. قمت بإعادة بناء حاوية Redis والآن يعمل كل شيء.

Sidekiq هي مكتبة للمهام الخلفية وتعتمد على Redis. إنها مُحسَّنة للغاية وناضجة، لكنها تدعم فقط واجهة Redis الخلفية.
أعتقد أيضًا أن message_bus (ميزات الوقت الفعلي في Discourse) تستخدم Redis في الخلفية.

8

تثبيت قياسي باستخدام حاويات Docker منفصلة حسب التعليمات (حتى أتمكن من بناء إصدار جديد من Discourse ثم التبديل السريع بين الإصدارين دون توقف)، لكنني لا أتعامل مع حاوية البيانات، والتي يبدو أن Redis يعمل داخلها (كنت أعتقد أنه سيعمل في الحاوية الرئيسية، ففوجئت بعدم عثور عليه يعمل فيها).

نعم، نفس الشيء تمامًا كما لدى @arrowcircle هنا. :slight_smile:

9

في إعداد يتكون من حاويتين، لا يزال يتعين عليك إعادة بناء حاوية البيانات، وأوصي بجدولتها سنويًا على الأقل

10

هل توجد طريقة للقيام بذلك دون توقف؟ كان هذا هو الهدف من فصلهما في البداية.

11

لتحقيق وقت توقف صفري، ستحتاج إلى تشغيل نسخة احتياطية من Redis ونسخة احتياطية من قاعدة البيانات. ومع ذلك، ستظل هناك مرحلة قصيرة للقراءة فقط أثناء عملية التحويل.

نعم، كل هذه الأمور ممكنة، لكنها تتطلب توظيف فريق بنية تحتية.

12

كل شيء مفتوح المصدر هنا، بدون مال. ^.^;