سكريبت Sidekiq runit هش للغاية: **discourse:www-data** **+ إجباري** **-L log/sidekiq.log** **يسبب تعطل لمدة ثانية واحدة**

الدعم
3

مرحباً — دعني أعيد صياغة هذا استنادًا بشكل صارم إلى حقائق وقت التشغيل من حاوية Docker الرسمية.

ما أراه في الحاوية قيد التشغيل (حقائق)

هذا تثبيت Docker رسمي مع runit (سير عمل مشغل /var/discourse القياسي؛ لا يوجد إعادة بناء مباشرة قبل الحادث). داخل الحاوية:

  1. توجد خدمة runit Sidekiq ويتم الإشراف عليها
ls -l /etc/service/sidekiq/run
sv status sidekiq

الناتج أثناء الحادث:

down: sidekiq: 1s, normally up, want up
  1. بدء تشغيل Sidekiq يدويًا يعمل
cd /var/www/discourse
sudo -u discourse bundle exec sidekiq -C config/sidekiq.yml

يبقى هذا قيد التشغيل، ويتصل بـ Redis، ويعالج المهام.

  1. **تصحيح /etc/service/sidekiq/run فقط (بدون إعادة بناء) يحل حلقة التعطل فورًا تم استبدال /etc/service/sidekiq/run بما يلي:
#!/bin/bash
exec 2>&1
cd /var/www/discourse
mkdir -p tmp/pids
chown discourse:discourse tmp/pids || true
exec chpst -u discourse:discourse \
  bash -lc 'cd /var/www/discourse && rm -f tmp/pids/sidekiq*.pid; exec bundle exec sidekiq -C config/sidekiq.yml'

بعد ذلك:

sv status sidekiq
run: sidekiq: (pid <PID>) <SECONDS>s

لذا، لا يتم تشغيل Sidekiq عبر Unicorn master في هذه الصورة؛ إنها خدمة runit يمكن أن يتعطل نص التشغيل الخاص بها في حلقة.

لماذا قد لا ترى الكود الدقيق في

discourse_docker

أتفق على أن النص الحرفي قد لا يكون في المستودع لأن /etc/service/sidekiq/run هو أثر وقت تشغيل يتم إنشاؤه/حقنه أثناء بناء الصورة/تشغيلها، وليس بالضرورة ملفًا مطابقًا في discourse_docker. ولكنه هو الخدمة الخاضعة للإشراف النشطة في هذه الصورة الرسمية، كما هو موضح أعلاه.

ما أثار الهشاشة (حقائق + استدلال بسيط)

  • لاحظنا أيضًا فشل logrotate اليومي بسبب أذونات Debian القياسية: /var/log = root:adm 0775، لذلك رفض logrotate التدوير حتى تمت إضافة su root adm عام.
  • عندما كان logrotate يفشل، كان يعيد إنشاء الملفات ضمن /shared/log/rails/، بما في ذلك sidekiq.log.
  • استخدم نص runit الافتراضي في هذه الصورة discourse:www-data وأجبر -L log/sidekiq.log على /shared/log، مما يجعل Sidekiq حساسًا للغاية لانحراف أذونات المجلد المشترك ويمكن أن يسبب خروجًا فوريًا قبل تسجيل الدخول المفيد.

الطلب / الاقتراح

بالنظر إلى ما سبق، هل يمكننا النظر في تقوية خدمة Docker/runit Sidekiq الافتراضية؟

الافتراضات المقترحة:

  • التشغيل كـ discourse:discourse (يتطابق مع الملكية النموذجية داخل الحاوية)،
  • البدء عبر bundle exec sidekiq -C config/sidekiq.yml،
  • تجنب فرض سجل مشترك -L log/sidekiq.log (أو جعله مرنًا).

سيمنع هذا حلقة التعطل الصامتة down: 1s التي توقف جميع مهام الخلفية/الذكاء الاصطناعي.

يسعدني اختبار أي فرع/تثبيت تشير إليه.