سؤال تشغيل عملية daemon من مغرور


أنا أقوم بتشغيل طلبي على VPS تحت Ubuntu 12.04 LTS.

ولدي مشكلة مع عملية daemon واحدة من تطبيقاتي. تسمى هذه العملية "delayed_job" (إذا لم تكن مألوفة - فهذا مجرد معالج مهمة في الخلفية).

المشكلة في هذه العملية هي أنه في بعض الأحيان يتم قتله (أفترض أنه بسبب وجود كمية محدودة من ذاكرة الوصول العشوائي على الخادم - فقط 1 غيغابايت).

لكن المشكلة الرئيسية في هذا الأمر هي أنها كذلك لست قادرا من تمهيد مرة أخرى بعد تعطل أو "قتل" إشارة ، على عكس "يونيكورن" (هو خادم التطبيق القضبان) ، والتي هي دائما الحصول على إعادة التمهيد بغض النظر عما يحدث لهم.

ونعم ، هذا هو صفقة كبيرة للغاية ، لأن الكثير من ميزات التطبيق تستخدم مهام الخلفية.

تحدث نفس القصة عندما تكون هناك أعمال صيانة على VPS (بدأها مالك VPS) وبعد إعادة التشغيل ، لن تكون عملية "delayed_job" موجودة في النظام بعد الآن.

هذا هو الأمر الذي أقوم بتشغيله كل مرة لإقلاعه: RAILS_ENV=production script/delayed_job start

إنها مشكلة معروفة ، لكن الحل الوحيد الذي وجدته على الإنترنت هو هذا المقال: http://www.alexreisner.com/code/upstart يشير ذلك إلى استخدام ميزة "مغرور" لنظام التشغيل Linux مع خيار "بيبودين" القادر على إعادة تشغيل العملية إذا تم قتلها أو تعطلها.

على الرغم من أن المقالة قديمة بعض الشيء ، إلا أنني اكتشفت أن Ubuntu 12.04 يجب أن يدعم هذه الميزة وأنشأت رابطًا رمزيًا في /etc/init الدليل (لقد قمت بتسميته: delayed_job.conf) إلى ملف "delayed_job" الذي قمت بوضعه في أحد مجلدات التطبيقات الخاصة بي (app_name / config ، على وجه الدقة) - لقد فعلت كل ما تقوله هذه المقالة.

مشكلتي هي: عندما أحاول تشغيل هذه العملية الجديدة (start delayed_job) في وحدة التحكم أحصل على:

delayed_job start/running, process 6000

ولكن في الواقع - يتم إنشاء أي عملية "delayed_job" على الإطلاق.

والحالة (status delayed_job) من عملية initctl لا تزال: delayed_job stop/waiting

بعد أن أعدم kill -9 6000 انا حصلت -bash: kill: (6000) - No such process

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

هل هناك أي شيء يمكنني محاولة جعله يعمل ، أو أنها غير مجدية؟


4
2018-02-23 19:11


الأصل




الأجوبة:


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

لاحظ أنه إذا كان التطبيق الخاص بك شديد الضخامة (بمعنى أنه يتشعب أكثر من مرتين) لتستطيع شركة Upstart تتبع Pid الخاص بها ، فقد تتمكن من تتبع ذلك بنفسك. قد يحتوي التطبيق على آلية لكتابة ملف pid ، أو قد تتمكن من التقاطها start-stop-daemon. نرى هذه الإجابة عن مثال ، على وجه التحديد ، ملف pg_agent.conf.

تصحيح:

لاحظ أنه إذا تعذّر على Upstart تتبع تطبيق التطبيق ، فلن تتمكن من استخدام RESPAWN مقطع. في هذه الحالة ، قد لا تناسب Upstart احتياجاتك. ربما منتج منافس مثل foreverسوف. لا اعرف


4
2018-02-25 17:45



بلى. أنا لم أستخدم مقطع "نتوقع" على الإطلاق. شكر! سوف ألقي نظرة - Dmitri
حسنا ، الآن "ابدأ" و "توقف" كلا العمل ، ولكن ، عملية "delayed_job" ليست تمهيد المتابعة (وفقا ل ps aux | grep "delayed_job"). حاولت كلا الخيارين: شوكة و daemon - لا يعمل. - Dmitri
ما هو عدد شوكة؟ - Brian.D.Myers
يجب أن أحسبها باستخدام دعامة؟ ماذا أفعل إذا كان أكبر من 2 (deamon)؟ - Dmitri
نعم ، عد بسلاسة. راجع الجملة الأخيرة من إجابتي المعدلة للأفكار إذا كانت> 2. - Brian.D.Myers