Capistrano لا إعادة تشغيل مجموعات mongrel بشكل صحيح

Question

لدي مجموعة من ثلاثة mongrels تعمل تحت Nginx ، وأقوم بنشر التطبيق باستخدام Capistrano 2.4.3. عندما أقوم "بنشر" عندما يكون هناك نظام تشغيل ، فإن السلوك هو:

1. يتم نشر التطبيق. تم تحديث الرمز بنجاح.

2. في إخراج نشر CAP ، هناك:

   • تنفيذ "sudo -p 'sudo كلمة مرور:' mongrel_rails cluster :: retart -c /var/www/rails/myapp/current/config/mongrel_cluster.yml"
   • الخوادم: ["myip"
   • myip] تنفيذ الأمر
   • ** [Out :: myip] إيقاف المنفذ 9096
   • ** [Out :: Myip] إيقاف المنفذ 9097
   • ** [Out :: Myip] إيقاف المنفذ 9098
   • ** [Out :: myip] بدأ بالفعل المنفذ 9096
   • ** [Out :: myip] بدأ بالفعل المنفذ 9097
   • ** [Out :: myip] بدأ بالفعل المنفذ 9098
3. أتحقق مباشرة من الخادم وأجد أن Mongrel لا يزال قيد التشغيل ، ولا تزال ملفات PID موجودة في الحالات الثلاث السابقة.
4. بعد وقت قصير (أقل من دقيقة واحدة) ، أجد أن Mongrel لم يعد قيد التشغيل ، وقد اختفت ملفات PID ، وفشلت في إعادة التشغيل.
5. إذا بدأت mongrel على الخادم باليد ، يبدأ التطبيق على ما يرام.

يبدو أن "Mongrel_Rails Cluster :: Restart" لا ينتظر بشكل صحيح توقف كامل قبل محاولة إعادة تشغيل المجموعة. كيف أقوم بتشخيص هذه المشكلة وإصلاحها؟

تحرير: هنا الجواب:

mongrel_cluster ، في مهمة "إعادة التشغيل" ، ببساطة يفعل هذا:

 def run
   stop
   start
 end

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

Answer 1

يمكنك إخبار وصفات mongrel_cluster بشكل صريح لإزالة ملفات PID قبل البدء بإضافة ما يلي في وصفات Capistrano:

# helps keep mongrel pid files clean
set :mongrel_clean, true

هذا يؤدي إلى تمرير الخيار -النحلي إلى mongrel_cluster_ctl.

عدت ونظرت إلى إحدى وصفات النشر الخاصة بي ولاحظت أنني قد غيرت أيضًا الطريقة التي عملت بها مهمتي لإعادة التشغيل. ألقِ نظرة على الرسالة التالية في مجموعة مستخدمي Mongrel:

مناقشة مستخدمي Mongrel لإعادة التشغيل

ما يلي هو نشرتي: إعادة التشغيل. أعترف أنه جزء من الاختراق.

namespace :deploy do
  desc "Restart the Mongrel processes on the app server."
  task :restart, :roles => :app do
    mongrel.cluster.stop
    sleep 2.5
    mongrel.cluster.start
  end
end

Answer 2

أولاً ، تضييق نطاق الاختبار الخاص بك عن طريق الاتصال فقط cap deploy:restart. قد ترغب في تمرير --debug خيار المطالبة قبل التنفيذ عن بُعد أو --dry-run الخيار فقط لمعرفة ما يجري أثناء تعديل الإعدادات الخاصة بك.

للوهلة الأولى ، يبدو هذا وكأنه مشكلة في ملفات PID أو عمليات mongrel ، ولكن من الصعب معرفتها بالتأكيد. هناك شيءان يلفت انتباهي:

• ال :runner المتغير هو التعبير nil - هل كان هناك سبب محدد لهذا؟
• Capistrano 2.4 قدم سلوكًا جديدًا لـ :admin_runner عامل. دون رؤية الوصفة بأكملها ، هل هذا ربما يتعلق بمشكلتك؟

  : Runner vs.: admin_runner (من Capistrano 2.4 إصدار) لاحظت بعض Cappers أن النشر: الإعداد والنشر: تنظيف التشغيل كـ: مستخدم عداء أذوناتهم المصنوعة بعناية. وافقت على أن هذه كانت مشكلة. من خلال هذا الإصدار ، نشر: ابدأ ، نشر: توقف ، ونشر: إعادة تشغيل جميعها ، تابع استخدام المستخدم: Runner ats at sudoing ، ولكن sefply: الإعداد والنشر: سوف يستخدم التنظيف: admin_runner user. متغير: admin_runner غير مستقر ، بشكل افتراضي ، مما يعني أن هذه المهام ستعمل على أنها جذر ، ولكن إذا كنت تريد أن يتم تشغيلها على النحو التالي: Runner ، فقط قم بـ "Set: admin_runner ، Runner".

توصيتي لما يجب القيام به بعد ذلك. توقف يدويًا من mongrels وتنظيف PIDs. بدء mongrels يدويا. بعد ذلك ، استمر في الجري cap deploy:restart أثناء تصحيح المشكلة. كرر حسب الضرورة.

Answer 3

في كلتا الحالتين ، تبدأ mongrels قبل أن ينتهي الأمر السابق في الإغلاق.

Sleep 2.5 ليس حلاً جيدًا ، إذا استغرق الأمر أطول من 2.5 ثانية لوقف جميع المغول الجري.

يبدو أن هناك حاجة ل:

stop && start

ضد.

stop; start

(هذه هي الطريقة التي يعمل بها Bash ، && تنتظر الأمر الأول ينهي خطأ w/o ، بينما "؛ ببساطة يدير الأمر التالي).

أتساءل عما إذا كان هناك:

wait cluster_stop
then cluster_start

Answer 4

أنا أكره أن أكون أساسيًا للغاية ، لكن يبدو أن ملفات PID لا تزال تتسكع عندما تحاول البدء. تأكد من توقف mongrel باليد. تنظيف ملفات PID باليد. ثم قم بنشر الحد الأقصى.

Answer 5

مناقشة جيدة: http://www.ruby-forum.com/topic/139734#745030