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

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

+1 لهذا الخيار

+1

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

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

سأكون سعيدًا بالمساهمة في طلب السحب ، أحتاج فقط إلى بعض المؤشرات حول المكان الذي يجب أن أبدأ فيه في الكود.

أيضًا ، لا أعرف ما إذا كان يجب علي إنشاء مشكلة أخرى لهذا ...

+1 ... طلب ​​معقول جدا فلماذا لا تكريمه؟

في عداد المفقودين هذا أيضا ....

هل هناك حل يسمح لنا على الأقل بإنشاء الدليل من داخل ملف التكوين؟ ربما تشغيل mkdir بالداخل؟

+1

يجب علينا نحن مستخدمى الرصيف القيام بذلك

1. ENTRYPOINT["sh", "/entrypoint.sh"] في ملف Dockerfile
2. في /entrypoint.sh ، أنشئ دليل السجل وملفات السجل قبل استدعاء المشرف

هذا نص برمجي لـ /entrypoint.sh لإنشائه من supervisord.conf تلقائيًا.

# Create log dirs and files
mkdir -p $( dirname $(cat /etc/supervisord.conf  | grep logfile= | grep "\.log" | sed s/.*logfile=// ) )
touch $( cat /etc/supervisord.conf  | grep logfile= | grep "\.log" | sed s/.*logfile=// )

# Then run supervisord
/usr/bin/supervisord

هل هناك فكرة جيدة؟

+1

supervisord لا يبدأ عند الإقلاع لنظام Arch Linux لأن /var/log/supervisord.log غير موجود عند الإقلاع.

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

mnaberez لماذا تتمسك برفضك؟ لقد رأيت حججًا أقوى لصالح هذا أكثر من رفضك ... (لكن ربما أفتقد شيئًا ما ، لذا نرحب بالمزيد من التفسيرات ؛-)

لا تزال هذه مشكلة ، خاصة للمستخدمين الذين ينشرون المشرف داخل Docker في بيئة ElasticBeanstalk. إذا حددت تسجيل الدخول في Dockerrun ، فإن الخدمة تمسح الدلائل المحددة أثناء النشر ، وتحذف أي شيء تم إنشاؤه أثناء دوران Docker. وهذا بدوره يكسر المشرف ، لأنه يتوقع عدم وجود ملفات. إذا أنشأ المشرف ببساطة أدلة وسجلات في حالة عدم وجود أي منها ، فسيحل المشكلة تمامًا. كما هو الحال ، اضطررت إلى تعطيل ملفات السجل المنفصلة (واستخدام سجل النظام بدلاً من ذلك) من أجل نشر تطبيقي.

نفس الشيء هنا ، لقد استخدمت الحل التالي:
docker run -v / mnt / my_logs / celery: / var / log / celery -v / mnt / my_logs / supervisor: / var / log / supervisor -v / mnt / my_logs / supervisor: / var / log / supervisor -v / mnt / my_logs / nginx: / var / log / nginx -v / mnt / my_media: / home / project / media -p 80:80 -p 5555: 5555 -d my_project

أنا أيضا أواجه هذا الآن. لدي Raspberry Pi الذي يحتوي على / var / log مثبت على tmpfs لمنع الكتابة على بطاقة SD. بعد إعادة تشغيل الجهاز ، يختفي المجلد / var / log / supervisor ولا يبدأ المشرف. سيكون إنشاء هذا الدليل تلقائيًا ميزة مرحب بها كثيرًا.

mnaberez هل تمانع في إعادة النظر؟ كانت هناك عروض للعلاقات العامة لهذه الميزة أيضًا.

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

: +1: لقد واجهت هذا أيضًا.

+1 👍 سيكون مفيدًا جدًا بالنسبة لي أيضًا.

يرجى تذكير هنا.
إذا تم تثبيت المشرف افتراضيًا ولم تقم بتغيير مسار السجل الخاص به من /tmp/supervisord.log ، في نظام معين مثل CentOS 7.3 أو أعلى ، سيقوم systemd-tmpfiles-clean.timer بعمل cron لحذف كل شيء تحت / tmp كل يوم .
لقد عانينا من هذا كثيرًا ...

لقد قمت للتو بتحرير ملف /etc/supervisor/supervisord.conf وقمت بتغيير هذه الأسطر ؛

logfile=/var/log/supervisor/supervisord.log إلى logfile=/var/log/supervisord.log
childlogdir=/var/log/supervisor إلى childlogdir=/var/log/

وثابت بالنسبة لي. وكنت نفس الموقف بشكل مثير مع adamreisnz :)

لم يكن عامل التحميل موجودًا عند إنشاء هذه المشكلة. لذلك ، نستخدم المشرف في عامل الميناء في الوقت الحاضر. شكرا انها أداة جميلة.

ومع ذلك ، إذا أردنا إعادة توجيه المخرجات ، فعلينا إضافة سطر جديد (وإنشاء طبقة جديدة) إلى ملف عامل الإرساء مثل mkdir /var/log/supervisord/"

إذا قام المشرف بإنشاء الدليل فسيكون ذلك جيدًا. شكرا على كل حال.

لا أعرف أي برنامج آخر لا يعرف كيفية إنشاء مجلدات السجل الخاصة به ، ناهيك عن رفضه للتشغيل إذا لم يكن موجودًا

صدم

+1

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

نظرًا لحقيقة أن المشرف هو أول من يتم تشغيله (قبل إنشاء دليل السجل بواسطة البرنامج الذي يبدأ تشغيله)

إذا كنت تبدأ myprogram مباشرة:

command = myprogram

يمكنك بدلاً من ذلك البدء بشيء مثل:

command = bash -c 'mkdir /foo && exec myprogram'

: +1: +1 لهذا الطلب

1063

+1 يرغب في استخدام اسم البرنامج في مسار السجل. ليس من الواضح تمامًا سبب عدم بدء المشرف عند حدوث ذلك

أيضا الحصول على نفس هذه المشكلة مؤخرا. فوجئت تمامًا بأنها لم تتعامل مع هذا داخليًا.

mnaberez أنت تقترح وضعه في الأمر ، لكن هذا لا يعمل مع سجلات المشرف ، كما أضعه في تعليق في هذا الموضوع:

And it is not possible to put it in the command directive, as supervisord complains and 
stops even before looking at the command

هل يمكنك إنشاء الدلائل قبل بدء المشرف ، على سبيل المثال في نص البادئ أو ما يعادله الذي يقوم بتشغيل المشرف؟ لما لا؟

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

من الواضح أيضًا أن غالبية البرامج الموجودة تفعل ذلك في الواقع ، لذلك من العدل أن يتوقع الناس ذلك.

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

لذلك أعتقد أن الأمر لا يتعلق بما إذا كان بإمكاننا أو لا نستطيع أن نجعل سكربتات التهيئة الخاصة بنا تُنشئ الدليل - يمكننا ذلك ، وفي حالتنا لدينا - ولكن السؤال عن سبب عدم قدرة المشرف على القيام بذلك بنفسه.

هناك 26 مشاركًا في هذا الموضوع وحده ، وهذا يعني أن هناك ما لا يقل عن 10 أضعاف عدد الأشخاص الذين لا يكلفون أنفسهم عناء التعليق هنا ويشعرون بنفس الطريقة حيال هذه المشكلة. إذا كانت هناك رغبة قوية في ما يعتبر للوهلة الأولى ميزة تافهة جدًا يجب طلبها ، فلماذا لا ننفذها فقط أو تطلب من شخص ما تقديم علاقات عامة؟

أود أيضًا أن أضيف ذلك لمشكلة بهذا الحجم ، على سبيل المثال ، لا يبدأ التطبيق بأكمله إذا لم يكن هناك دليل يجب إنشاؤه يدويًا ، فهناك القليل من الوثائق المدهشة حول هذه الحقيقة.

http://supervisord.org/logging.html
http://supervisord.org/faq.html
http://supervisord.org/installing.html

لم تذكر أي من هذه الصفحات أي شيء عن الحاجة إلى إنشاء أدلة السجل يدويًا.

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

من الواضح أيضًا أن غالبية البرامج الموجودة تفعل ذلك في الواقع ، لذلك من العدل أن يتوقع الناس ذلك.

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

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

هذه هي رسالة الخطأ الفعلية:

Error: The directory named as part of the path /nonexistant/cat/stdout.log does not exist in section 'program:cat' (file: 'supervisord.conf')
For help, use /usr/local/bin/supervisord -h

إذا كان هذا غير واضح فكيف يمكن إعادة صياغته؟

إذا كانت هناك رغبة قوية في ما يعتبر للوهلة الأولى ميزة تافهة جدًا يجب طلبها ، فلماذا لا ننفذها فقط أو تطلب من شخص ما تقديم علاقات عامة؟

• السلوك الحالي يمنع أخطاء التكوين. حاليًا ، إذا كان النظام يحتوي على دليل /var/log/ ولكنك أدخلت عن طريق الخطأ /var/logs/foo.txt في ملف التكوين ، فإن supervisord سيتوقف مع الخطأ أعلاه. أعتقد أن هذا أفضل من الحصول على كل من /var/log/ و /var/logs/ وربما عدم ملاحظة ذلك لفترة طويلة.

• ماذا يعني إنشاء الدليل تلقائيًا ، بالضبط؟ هل هذا يعني mkdir أو mkdir -p ؟ ماذا يجب أن يكون chown و chmod للأدلة التي تم إنشاؤها تلقائيًا؟ حاليًا ، يقوم المستخدم بإعداد كل هذه الأشياء خارج supervisord مع shell. هل يحتاج ملف التكوين إلى مجموعة من الخيارات لتحديدها جميعًا الآن؟ إذا كان لدى البرامج الأخرى هذا السلوك ، فهل يمكن لشخص ما إعطاء أمثلة محددة من فضلك؟

• هل هي مجرد سجلات أم يجب أن ينطبق هذا على مسارات أخرى أيضًا ، مثل ملفات pidfiles؟ لما و لما لا؟ إذا لم يكن الأمر كذلك ، ألن يكون من الأفضل أن تكون متسقًا ولا تنشئ أي دليل بدلاً من إنشاء البعض وليس البعض الآخر؟

أود أيضًا أن أضيف ذلك لمشكلة بهذا الحجم ، على سبيل المثال ، لا يبدأ التطبيق بأكمله إذا لم يكن هناك دليل يجب إنشاؤه يدويًا ، فهناك القليل من الوثائق المدهشة حول هذه الحقيقة.

يعد Fail-fast أسلوبًا شائعًا عند بدء البرامج الخادعة وبرامج الخادم الأخرى بتكوين سيئ. لا توجد وثائق توضح خيارات التكوين التي يُسمح لها بأن تكون غير صالحة وأي منها ليس بسبب عدم وجود أي منها.

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

سيكون البديل هو تمكين supervisord بطريقة ما للبدء جزئيًا بتكوين معطل معروف ، وربما محاولة تجاهل الخيارات غير الصالحة فقط. وهذا من شأنه أن يجعل عمليتها غير متوقعة ويؤخر حل المشكلات.

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

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

لقد حاولت العثور على حل معقول لإنشاء أدلة حيث يرسل المشرف السجلات ، ولكن لا شيء يعمل (أضف إنشاء ملف السجل في command="mkdir blah && command" ) وهو سهل وقابل للصيانة (قم بتحليل ملف السجل لإنشاء الدلائل قبل البدء المشرف).

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

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

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

فيما يتعلق بـ "لماذا لا تسهل حياة المستخدمين لديك؟" والتعليقات المماثلة ، من الواضح أنني قضيت الكثير من الوقت في الرد على التعليقات هنا ومحاولة فهم هذه المشكلة بشكل أفضل. أنا أهتم بالمستخدمين وهذا هو السبب في أنني أمضيت ما يقرب من عشر سنوات في صيانة هذا البرنامج وإصلاح المشكلات والرد على القائمة البريدية. عندما ترسل تعليقات من هذا القبيل إلى المشرفين على المصادر المفتوحة ، فإن ذلك يجعلها مهمة نزيهة بالفعل بائسة وتؤدي إلى الإرهاق.

تحرير: إعادة صياغة ؛

في هذه الحالة ، حدد المستخدم ملف سجل اختياري ولكن المشرف لا يمكنه إنشاء ملف السجل هذا لأن الدليل الذي حدده المستخدم غير موجود

هذا هو الشيء ، في حالتي ، يتم تثبيت المشرف بواسطة برنامج آخر (Dataplicity) ، لمراقبة / بدء تطبيقهم. لا أقوم بتكوين المشرف بنفسي ، لذلك لا أحدد مكان تسجيله أو ما إذا كان يجب تسجيله على الإطلاق.

كل ما أعرفه هو أنه سبب لي الكثير من الحزن بسبب فقد مجلد ، واضطررت إلى تعديل البرامج النصية لبدء التشغيل لإنشاء المجلد يدويًا بعد كل إعادة تشغيل (لأنه على tmpfs ).

إذن من المسؤول في هذه الحالة؟ أنت تقول إن المشرف لا يقوم بالتسجيل افتراضيًا ، لذلك يستخدم Dataplicity مشرفًا (ويفترض) يقوم بتكوينه لاستخدام ملف السجل. ولكن بعد ذلك ، لا يعرف Dataplicity أي شيء عن حالة الجهاز الذي يعمل عليه ، لذلك لا يمكنهم حقًا معرفة مجلدات السجل التي سيتم إنشاؤها أيضًا. المستخدم عالق في المنتصف لأنه لا يعرف أنه يحتاج إلى إنشاء مجلد سجل إلا بعد أن يواجه الخطأ بعد إعادة التشغيل. إذاً فهو قليلاً من وضع الدجاجة والبيض.

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

لقد فهمت وجهة نظرك والآن بعد أن فهمت أن ملف السجل ليس إعدادًا افتراضيًا ، أعتقد أنني أفهم سبب عدم إزعاجك بإنشاء المجلد. بعد كل شيء إذا كان المستخدم يحدد المجلد ، فعليهم التأكد من وجوده. أتفق تماما.

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

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

mnaberez شكرًا جزيلاً لإعادة النظر في هذا وعلى جميع الردود. لقد كنت أراجع تعليقاتي الأصلية (منذ سنوات عديدة) لأفهم بشكل أفضل سبب إنشاء هذه المشكلة في المقام الأول.

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

أشارك الكثير من مخاوفك بشأن إنشاء أدلة السجل الخاصة بالمشرف. وبعد التفكير في الأمر ، قمت بحل كلتا المشكلتين بنفس الطريقة: بالنسبة للمشرف ، أقوم بإنشاء أدلة السجل في ملف init (systemd في الوقت الحاضر) ، وبالنسبة للبرامج ، أستخدم نوعًا من "init script" (bash) لـ ثم ، وهذا البرنامج النصي مسؤول عن إنشاء أدلة السجل إذا لم تكن موجودة (و "execs" البرنامج بعد ذلك).

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

ردا على تعليقات الجميع هنا. أود أن أقول أيضًا أنه إذا كان هذا أمرًا يصعب تحقيقه ، فكل ما عليك هو تحسين رسائل الخطأ وتوثيق ذلك بالفعل في أماكن مختلفة وفي عملية الإعداد ، فسيؤدي ذلك إلى تبسيط العملية للمستخدمين.

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

تعد أذونات المجلد مشكلة شائعة ، لذا لا أعتقد أن وجود القليل من الوثائق حول هذا كجزء من الإعداد سيؤثر سلبًا على هذه العملية.

فيما يتعلق بـ "لماذا لا تسهل حياة المستخدمين لديك؟" والتعليقات المماثلة ، من الواضح أنني قضيت الكثير من الوقت في الرد على التعليقات هنا ومحاولة فهم هذه المشكلة بشكل أفضل. أنا أهتم بالمستخدمين وهذا هو السبب في أنني أمضيت ما يقرب من عشر سنوات في صيانة هذا البرنامج وإصلاح المشكلات والرد على القائمة البريدية. عندما ترسل تعليقات من هذا القبيل إلى المشرفين على المصادر المفتوحة ، فإن ذلك يجعلها مهمة نزيهة بالفعل بائسة وتؤدي إلى الإرهاق.

mnaberez يسعدني أنك تعيد النظر في هذا الطلب ، وأنا أقدر تفانيك في مشروعك. كان من المفترض دائمًا أن تكون تعليقاتي محترمة وأشعر أن سؤالي مبرر لطلب يحظى باهتمام متكرر من المستخدمين منذ عام 2012.

فيما يتعلق بالطلب نفسه ، فإن المشكلة التي واجهتها هي أن المشرف يشكو من السجل غير الموجود قبل بدء الأمر. الأسهل هو السماح للمستخدم بإنشاء الدلائل إما عن طريق دمجها في الأمر (مثل mkdir /var/log/supervisord && mycommand ) ، ولكن قد يكون لذلك بعض التأثير على العناصر الداخلية ، أو من خلال الحصول على توجيه PreCommand لـ الذي لا يشترط وجود السجل دير.

كان من المفترض دائمًا أن تكون تعليقاتي محترمة وأشعر أن سؤالي مبرر لطلب يحظى باهتمام متكرر من المستخدمين منذ عام 2012.

التعليقات السلبية مثل "لماذا لا تسهل فقط حياة المستخدمين؟" لا تكون أبدًا محترمة أو مبررة.

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

لست متأكدًا مما يجب فعله بشأن هذه المشكلة ، لكنني أتفق مع adamreisnz و Dayjo على أن تحديث الوثائق لتوضيح السلوك الحالي هو خطوة أولى جيدة.

التعليقات السلبية مثل "لماذا لا تسهل فقط حياة المستخدمين؟" لا تكون أبدًا محترمة أو مبررة.

كتعليقي الأخير على هذه المسألة ، أشجعك على قراءة http://www.dealingwithdisrespect.com . أشعر أن تعليقي مقبول ، وبعيدًا عن كونه غير مقبول.

هذا هو الشيء ، في حالتي ، يتم تثبيت المشرف بواسطة برنامج آخر (Dataplicity) ، لمراقبة / بدء تطبيقهم. لا أقوم بتكوين المشرف بنفسي ، لذلك لا أحدد مكان تسجيله أو ما إذا كان يجب تسجيله على الإطلاق.

كل ما أعرفه هو أنه سبب لي الكثير من الحزن بسبب فقد مجلد ، واضطررت إلى تعديل البرامج النصية لبدء التشغيل لإنشاء المجلد يدويًا بعد كل إعادة تشغيل (لأنه على tmpfs).

إذن من المسؤول في هذه الحالة؟

لست على دراية بـ Dataplicity ولكن قد ترغب في إبلاغ Dataplicity بهذه المشكلة أيضًا.

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

إذا فهمت بشكل صحيح ، فإن Dataplicity قام بتثبيت المشرف نيابة عنك ولكن الطريقة التي تم تثبيته بها لن تنجو من إعادة التشغيل على نظامك. تم إنشاء دلائل السجل في البداية بواسطة Dataplicity ولكنها لم تستمر بعد إعادة التشغيل لأنها كانت على tmpfs. إذا كان Dataplicity يقوم بإنشاء البرنامج النصي الأولي الذي يبدأ تشغيل Supervisor ، فقد يتمكنون من تغيير البرنامج النصي الخاص بـ init بحيث يقوم بالتحقق من الدلائل أولاً وإنشاءها إذا لزم الأمر (نفس الحل الذي قمت به). قد يرغبون أيضًا في تتبع هذه التذكرة لأنه حتى إذا تم إجراء تغيير على المشرف أو تمت إضافة ميزة جديدة ، فقد لا تلتقط Dataplicity الإصدار الجديد تلقائيًا إذا تم تثبيتها في إصدار معين.

تضمين التغريدة

يقوم وكيل تثبيت البيانات لدينا بتنزيل وتثبيت المشرف. عندما يتم تنزيله ، فإنه يحتوي على جميع الإعدادات كما تم تكوينه في المنبع ، ونحن لا نغير أي شيء. يمكن رؤية الدليل الافتراضي الذي يستخدمه المشرف للتسجيل في الملف أدناه. هذا ما قد ترغب في تعديله على الأرجح إذا كنت ترغب في تخزين سجلاتك في مكان آخر.

cat /etc/supervisor/supervisord.conf

; supervisor config file

[unix_http_server]
file=/var/run/supervisor.sock   ; (the path to the socket file)
chmod=0700                       ; sockef file mode (default 0700)

[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)

--- ... shortened output ... ---

بالنسبة إلى سجلات البيانات المحددة ، يوجد أدناه ملف الوحدة الخاص بنا للمشرف الذي يحدد مكان الاحتفاظ بها.

cat /etc/supervisor/conf.d/tuxtunnel.conf

--- ... shortened output ... ---

stdout_logfile=/var/log/dataplicity.log
stderr_logfile=/var/log/dataplicity.log

بدلاً من ذلك ، إذا كنت ترغب في الاحتفاظ بملفات السجل في مكانها والتأكد فقط من أن المشرف يعمل مع tmpfs ، فإليك شيئًا يمكنك إضافته إلى ملف /etc/rc.local الخاص بك:

if [ ! -d /var/log/supervisor ]; then
        mkdir /var/log/supervisor;
        touch /var/log/supervisor/supervisord.log
        chown -R dataplicity:dataplicity /var/log/supervisor;
        service supervisor restart
fi

أتمنى أن يساعدك هذا،
رادوسلاف من Dataplicity

تضمين التغريدة

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

إذن هذه هي الإعدادات الافتراضية للمشرف؟ مما فهمته مما كتبه mnaberez ؛

في هذه الحالة ، حدد المستخدم ملف سجل اختياري ولكن المشرف لا يمكنه إنشاء ملف السجل هذا لأن الدليل الذي حدده المستخدم غير موجود.

اعتقدت أن المشرف لا ينشئ أي سجلات أو يحدد أي أدلة سجلات بشكل افتراضي.

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

ليس من المنطقي أن يكون لدى imo دليل افتراضي ولكن بعد ذلك يتعذر بدء تشغيل التطبيق لأن الدليل غير موجود.

تضمين التغريدة

هذه هي الإعدادات الافتراضية للمشرف ، صحيحة.

أنت محق في أن:

_ "ليس من المنطقي أن يكون لدى imo دليل افتراضي ولكن بعد ذلك يتعذر بدء تشغيل التطبيق لأن الدليل غير موجود." _

واجه شباب emonpi الذين كانوا في الماضي يقومون بتثبيت البيانات على نظامهم نفس المشكلة وأعتقد أنه تم الإبلاغ عنها لمطوري المشرف ولكن ردهم كان مسؤولية المستخدم عن إنشاء هذا الدليل إذا لم يكن موجودًا.

أفضل،
رادوسلاف من Dataplicity

هذه هي الإعدادات الافتراضية للمشرف ، صحيحة.

هذا غير صحيح لأن هذا المشروع (المشرف) لا يوفر برامج نصية أو ملفات تهيئة على الإطلاق (انظر المزيد أعلاه ). نحن نوفر فقط أمرًا ، echo_supervisord_conf ، يكتب نموذجًا للتكوين إلى stdout. لقد نظرت إلى التكوين الخاص بك أعلاه ، وهو لا يتطابق مع الناتج بواسطة echo_supervisord_conf (على سبيل المثال ، لا تظهر الدلائل /var/run و /var/log في أي مكان في هذا النموذج الناتج). أنت تستخدم تكوينًا تم إنشاؤه وكتابته على القرص بواسطة شخص آخر.

يقوم وكيل تثبيت البيانات لدينا بتنزيل وتثبيت المشرف. عندما يتم تنزيله ، فإنه يحتوي على جميع الإعدادات كما تم تكوينه في المنبع ، ونحن لا نغير أي شيء.

يوفر مشروع المشرف حزم Python التي يتم نشرها إلى PyPI فقط . يتم تثبيت حزمنا عادةً بـ pip . لا تحتوي حزمنا على برامج نصية أو ملفات تهيئة. يبدو أنك تقوم بتثبيت الحزمة من مصدر آخر ، على سبيل المثال ، ربما قمت بتثبيتها باستخدام أمر مثل apt أو rpm . هذه حزم تابعة لجهات خارجية تم إنشاؤها بواسطة أشخاص آخرين غير مشاركين في مشروع المشرف الرئيسي. لا نعرف الكثير عن هذه الحزم ولا يمكننا إجراء تغييرات عليها. أي نصوص أولية أو ملفات تهيئة تأتي منها. أقترح الاتصال بقائمين على صيانة حزمة الطرف الثالث التي تقوم بتثبيتها. هم الوحيدون الذين سيكونون قادرين على تعديل البرنامج النصي الافتراضي الخاص بهم لإنشاء الدلائل.

أهلا،
أنا أكتب للتو لتقديم القليل من التعبئة هنا ولتوضيح أمر أو شيئين منذ أن تمت الإشارة إلى Dataplicity أكثر من مرة هنا :-)

أولاً ، نشكر الجميع على الاهتمام المتجدد بهذه المشكلة ، وشكرًا للمشرف المطورين على وجه الخصوص لتخصيصه الكثير من الوقت والجهد لعفريت المشرف الذي نعتمد عليه لتشغيل Dataplicity Agent على الأجهزة.

تم بالفعل وصف المشكلة الدقيقة بالنسبة لنا جيدًا أعلاه. السلوك المتعلق بإنشاء دليل السجل إذا لم يكن موجودًا لا يخلو من سابقة. على وجه الخصوص ، لدى nginx سلوك مشابه (لا يُنشئ الدليل) ، كما يفعل عدد من الخدمات السائدة الأخرى. كما يحدث ، أنتج adamreisnz قائمة جيدة جدًا في مستودعات emonpi حيث يجب التلاعب بكل خدمة بها هذه المشكلة بنفس الطريقة بالضبط.

إذا كنت سأقوم بملاحظة واسعة جدًا ، فإن الجديد الآن على عكس ما كان عليه قبل خمس سنوات هو أن تسجيل الدخول إلى التخزين المتطاير أصبح شائعًا بشكل متزايد. بتعبير أدق ، مع الوصول الجماعي لأجهزة إنترنت الأشياء (مثل Raspberry Pi) وأنظمة مثل Docker و Amazon EBS ، أصبح الناس يعتمدون بشكل متزايد على tmpfs للحصول على نظام تسجيل سريع لا يتآكل تخزين الفلاش. هذه ليست مشكلة على مستوى التوزيع - تتأثر جميع Ubuntu و Arch و Slackware بالمثل.

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

في حالة Dataplicity ، فإنه يؤثر علينا لأن SBCs بما في ذلك Raspberry Pi عادة ما تستخدم tmpfs لتخزين السجلات لمنع تآكل الفلاش. وفي معظم هذه الأنظمة ، هذا يعني أن / var / log هو نظام ملفات جديد لا يحتوي على أدلة في اللحظة التي يبدأ فيها التشغيل. وهو ما يعني بعد ذلك أن المشرف ينقطع عند بدء التشغيل لأنه لا يمكنه الوصول إلى الدليل الذي يتوقعه.

للتوضيح:
1) وكيل البيانات هو البرنامج الخفي من جانب الجهاز والذي يعمل على أجهزة المستخدم ، عادةً Raspberry Pi ، لتوصيل الجهاز بخدمة البيانات.
2) يستخدم الوكيل المشرف للتأكد من أننا نعمل كمستخدم غير متميز على النظام ، وللتعامل مع أشياء مثل إعادة التشغيل التلقائي للوكلاء وما إلى ذلك.
3) يستخدم مُثبِّت Dataplicity apt-get على الأنظمة التي تكون متاحة ، مما يعني نعم ، عملية التثبيت للمشرف مستمدة من مزيج من مصدر البرنامج (هنا) وإرشادات التثبيت الدقيقة المخبأة في حزمة apt بواسطة أشخاص التوزيع في Debian / Ubuntu وما إلى ذلك.

هناك ثلاثة أماكن يمكننا (Dataplicity) وضع شيء ما فيها لإنشاء هذا الدليل عند بدء التشغيل ، ولكن المكان الوحيد (بالنسبة لنا) دون عيوب كبيرة هو إذا كان المشرف سيُنشئ الدليل المتوقع نفسه عند بدء التشغيل.

المستوى 3 (على مستوى مُثبِّت سهولة البيانات / الوكيل)

• يمكننا وضع fudge في أداة تثبيت البيانات لإنشاء الدليل. لن يعمل هذا لأن الدليل هو tmpfs ولن ينجو من إعادة التشغيل.
• يمكننا وضع حلوى مختلفة في أداة تثبيت البيانات لتعديل rc.local أو في البرنامج النصي لبدء المشرف لإنشاء هذا الدليل عند التمهيد في كل مرة. في الاختبار الذي أجريناه ، فإن استخدام الأنظمة الأساسية لـ rc.local غير متسق ، مما يعني أنه لا يمكننا الاعتماد على هذا في كل توزيع بما في ذلك تلك التي يقوم فيها الأشخاص بتدوير تصميماتهم الخاصة (أمر شائع جدًا لمستخدمينا). هذا الأخير معقول ، ولكنه ينتهي أيضًا بالاعتماد على النظام الأساسي ويتعارض مع حزم التوزيع القياسية ، لذا فإن تحديثات التوزيع وما إلى ذلك ستقاتل باستمرار مع هراءنا الصغير. وبغض النظر عن سهولة البيانات ، يصعب توقع هذا السلوك لكل عملية تثبيت في نفس الموقف.
• يمكننا تعديل تكوين المشرف الافتراضي. ومع ذلك ، نظرًا لأن العديد من الأشياء يمكن أن تستخدم مشرفًا على نفس النظام ، فإن افتراض أن سهولة البيانات هو الشيء الوحيد الذي "يعمل" المشرف على الجهاز هو افتراض قوي جدًا: يمكن أن يصاب الناس بالضيق معنا إذا قمنا عن غير قصد بضرب خدمات أخرى تعمل على أجهزتهم.

خلاصة القول هي أن الأمر ينتهي بقليل من المراوغة بعد أن نقوم بـ "apt-get install Supervisor" علينا بعد ذلك القيام بـ "mkdir / var / log / supervisor /" فقط لجعله يعمل.

المستوى 2 - التوزيع

• يمكننا أن نطلب من كل موزع تغيير عملية التثبيت لضمان إنشاء أدلة معينة في كل مرة يقوم فيها النظام بالتمهيد. كما يحدث ، تقوم حزمة apt-get بالفعل بإنشاء الدليل الأولي لأنه يطابق ملفات تكوين القالب التي توفرها. لكن هذا لا يفسر حقيقة أن العديد من الأنظمة تعمل على tmpfs ، مما يعني أنها لا تنجو من إعادة التشغيل الأولى.

المستوى 1 - المشرف نفسه.

• أفهم أن هذا من المحتمل أن يضيف طبقة أخرى هنا. ولكن بخلاف إنشاء دليل ، لا أرى أي جانب سلبي (بالطبع قد أفتقد شيئًا ما).
• والفائدة هي أن هذا السلوك سوف يتدفق ويعني أن كل توزيع يدعم نظام ملفات مؤقت (أو ما يعادله) ، سيحصل في النهاية على هذا السلوك ، مما يعني أنه لا يتعين علينا إقناع كل توزيع بوضع هذا الخطأ في مكانه.

أتمنى أن يساعد ذلك.

إليوت (Dataplicity)

خلاصة القول هي أن الأمر ينتهي بقليل من المراوغة بعد أن نقوم بـ "apt-get install Supervisor" علينا بعد ذلك القيام بـ "mkdir / var / log / supervisor /" فقط لجعله يعمل.

الرجاء إبلاغ هذه التفاصيل نفسها إلى القائمين على صيانة الحزمة التي تقوم بتثبيتها. ويمكن أن تكون قادرة على مساعدة.

أهلا

لدينا عدد قليل من الخيارات ، ولكن من المرجح أن يأخذني هذا الخيار بعينه إلى التقاعد: إجراء هذا التغيير لجميع الأنظمة الأساسية التي ندعمها يصل إلى كل توزيع من Red Hat إلى arch عبر Ubuntu و Debian بينهما. كما أنه يفتقد إلى النقطة التي مفادها أن المشرف خارج الصندوق لا يعمل على أنظمة ذات مخزن سجلات متقلب.

هل هناك شيء أفتقده هنا ويمثل تحديًا معينًا أو حجة ضد القيام بذلك؟ هل من المحتمل أن يتسبب في مشكلات تتعلق بالصيانة أو النشر لست على علم بها؟

أفضل
إليوت

هل هناك شيء أفتقده هنا

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

الآن بعد أن استطعت أن أفهم تمامًا.

ومع ذلك ، فإن ما يشغلني هو دائمًا ما هو الحل الأفضل ، متبوعًا إلى حد ما بعد ذلك بما هو الأسرع.

إذن ما أراه هنا هو مشكلتان. أحدهما هو حل هذا الأمر بأفضل طريقة ممكنة ، اقتراحي الشخصي هو إضافة هذا في جميع الحزم الأولية (ما زلت منفتحًا على حلول أفضل أيضًا).

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

الأول هو حل هذه المشكلة بأفضل طريقة ممكنة ، اقتراحي الشخصي هو إضافة هذا في جميع الحزم الأولية

سنكون مهتمين بتعليقاتك (أو أي شخص آخر) على الأسئلة أعلاه . كان هناك طلب سحب أنشأ بصمت وبشكل تلقائي أي دليل مفقود. لا أعتقد أن هذا هو الشيء الصحيح الذي يجب فعله للسبب المذكور أعلاه ، لكنني لست متأكدًا من الشكل الذي يجب أن يبدو عليه الخيار الجديد.

mnaberez أرى سؤالك.

يقول الجانب الهندسي مني أن كل شيء يجب أن يكون متسقًا تمامًا. لكن الجانب العملي مني يقول أن هذه مشكلة تتعلق بشكل أساسي بـ / var / log الموجود على tmpfs ولم أسمع شكاوى في أي مكان آخر. بشكل عام ، أود أن أقترح أنه يمكن بالتالي إبقاء الحل ضيقًا في التركيز حتى يحين الوقت الذي يعتبر فيه من المناسب توسيع النطاق.

أضيق خيار يمكن أن أفكر فيه هو في الواقع مكدير ضمني. منطقتي هي أن المشكلات التي نراها تتعلق بنقص / var / log / Supervisor / عند التمهيد بدلاً من نقص / var / log ، وأنني نادراً ما صادفت عمليًا نظامًا لا يحتوي على دليل تسجيل المستوى الأعلى الذي يمليه الموزع.

سأقدم استجابة أكثر تفكيرًا غدًا.

بدلاً من إنشاء الدلائل بشكل ضمني ، هل يمكن أن يكون هناك قسم صريح في conf لضمان وجود الدلائل قبل إجراء العملية؟

شيء على هذا المنوال:

[directory:log]
path=/foo/bar/baz
owner=www-data
create=true
recursive=true

إذا حددت مسارًا فقط ، فسيفشل إذا لم يكن هذا المسار موجودًا (والذي قد يكون مفيدًا في حد ذاته). لكن create=true يعلن أنك تريد إنشائه (إذا لم يكن موجودًا) ، ويعلن recurse=true أنك تريد إنشاء أي مجلدات رئيسية.

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

في رأيي ، يجب أن يكون البرنامج الخفي للمشرف نفسه موثوقًا للغاية وأن يبدأ حتى لو كان هناك أي مشكلة في تكوين برامج معينة.

في حالتي ، أقوم بنشر تطبيقي في خطوتين:

1. خادم Bootstrap باستخدام الطاهي (تثبيت الحزم وإنشاء ملفات التكوين).
2. نشر التطبيق باستخدام capistrano (جلب التطبيق من جيثب وإعادة تشغيل خدمات معينة باستخدام المشرف ctl أعد تشغيل my_group: *.

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

لذلك بعد أول تشغيل للطاهي ، انتهى بي الأمر بمشرف معطل (الخدمة ميتة) لأنه لا يمكن العثور على دليل. ثم قم بتشغيل capistrano لنشر التطبيق للمرة الأولى (يقوم بإنشاء جميع الدلائل المطلوبة) ويحاول إعادة تشغيل الخدمات باستخدام supervisorctl ولكنه يفشل. لذلك أحتاج إلى تشغيل الشيف مرة أخرى وهو أمر مزعج.

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

+1

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

يوجد في الواقع مشكلتان رئيسيتان في سلوك المشرف الآن:

1. عدم إنشاء فرع الدليل تلقائيًا.
2. يتم الإغلاق تمامًا لمجرد أنه لا يمكن إنشاء بعض ملفات السجل. هذا أسوأ من المشكلة الأولى. (تم تناول هذا في # 1143 ، والذي أعتقد أنه _ليس_ نسخة مكررة.)

mnaberez كتب:

السلوك الحالي يمنع أخطاء التكوين. حاليًا ، إذا كان النظام يحتوي على دليل / var / log / ولكنك أدخلت /var/logs/foo.txt عن طريق الخطأ في ملف التكوين ، فسيتوقف المشرف بسبب الخطأ أعلاه. أعتقد أن هذا أفضل من الحصول على كل من / var / log / و / var / logs / وربما عدم ملاحظة ذلك لفترة طويلة.

تبدو مشكلة _ الافتراضية_ المتمثلة في إنشاء ملفات السجل عن طريق الخطأ في موقع خاطئ قليلاً مشكلة أقل بكثير بالنسبة لي من المشكلة الحقيقية والمتكررة (يجب أن تكون) المتمثلة في إسقاط الخادم بالكامل لمجرد أن المسؤول نسي إنشاء مجلد لـ ملف تسجيل.

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

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

ماذا يعني إنشاء الدليل تلقائيًا ، بالضبط؟ هل تعني مكدير ام مقدير ع؟

mkdir -p بالطبع. من وجهة نظر عملية بحتة ، لا يضطر المستخدم إلى التعامل مع بعض البرامج النصية المُجمعة أو تسلسلات الأوامر التابعة.

ماذا يجب أن يكون chown و chmod للأدلة التي تم إنشاؤها تلقائيًا؟

ماذا عن أنها تتوافق مع chown و chmod لملف السجل الذي تم إنشاؤه؟ تقوم بإنشاء ملف السجل نفسه ، أليس كذلك؟ لماذا لا تنشئ الدليل أيضًا؟

حاليًا ، يقوم المستخدم بإعداد كل هذه الأشياء خارج المشرف مع shell.

... وهو ما لم يفعلوه في البداية ، لكنهم اكتشفوا هذه المشكلة بعد تعطل خادمهم بشكل غير متوقع.

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

هل هي مجرد سجلات أم يجب أن ينطبق هذا على مسارات أخرى أيضًا ، مثل ملفات pidfiles؟ لما و لما لا؟

حسنًا ، يبدو أن هذا خارج نطاق المشكلة الحالية.

إذا لم يكن الأمر كذلك ، ألن يكون من الأفضل أن تكون متسقًا ولا تنشئ أي دليل بدلاً من إنشاء البعض وليس البعض الآخر؟

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

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

هذا الرأي خاص بالتطبيق. لن نخمن مدى أهمية ملفات السجل بالنسبة لتطبيق شخص آخر. إذا قدم المستخدم ملفًا supervisord.conf supervisord تنفيذه ، فسوف يفشل بسرعة حتى يتم تصحيح المشكلة عاجلاً وليس آجلاً.

تضمين التغريدة

تختلف السجلات عن الملفات الهامة على سبيل المثال والتي يعد تناسقها أمرًا حيويًا للنظام. السجلات مهمة ، لكنها ليست حرجة أو حيوية. ...

هذا الرأي خاص بالتطبيق.

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

لن نخمن مدى أهمية ملفات السجل بالنسبة لتطبيق شخص آخر.

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

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

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

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

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

السلوك الحالي يمنع أخطاء التكوين. حاليًا ، إذا كان النظام يحتوي على دليل / var / log / ولكنك أدخلت /var/logs/foo.txt عن طريق الخطأ في ملف التكوين ، فسيتوقف المشرف بسبب الخطأ أعلاه. أعتقد أن هذا أفضل من الحصول على كل من / var / log / و / var / logs / وربما عدم ملاحظة ذلك لفترة طويلة.

حسنًا ، لنفترض وجود خطأ في التكوين. ما هي النتيجة النهائية للخطأ المذكور؟ يتم إنشاء سجلات صالحة تمامًا وتخزينها في المكان الخطأ. عندما يبحث شخص ما عن السجلات ، فإنه لا يجدها في المكان الذي توقعه ، لذلك ينتقل إلى ملف التكوين ، ويرى أن وجهة السجل قد تمت تهيئتها بشكل غير صحيح ... وتصحيحها. في غضون ذلك ، لديهم كل السجلات السابقة ، ولم ينكسر أي شيء في غضون ذلك. إذا حدث عطل ما (دعنا نقول أن هناك مُجمِّع يعمل ولم يكن يجمع السجلات لأنها لم تكن في المكان المناسب) ، عندها يمكن أن يحدث أمر واحد فقط:

1. فشلت خدمة التجميع بسبب خطأ عدم العثور على السجلات المتوقعة (مما قد يؤدي إلى إجراء تحقيق قد يؤدي إلى ملف التكوين) ، أو:
2. لا تتضمن خدمة التجميع سجلات المشرف ، وفي هذه الحالة يلاحظ أي شخص يقوم بفحص المجمع عدم وجود السجلات ، ثم يذهب للعثور عليها يدويًا ، ويكتشف التناقض. وفي الوقت نفسه ، يستمر تشغيل جميع الخدمات ، وتم إنشاء السجلات ، بحيث يمكن تحميلها يدويًا إلى المجمّع دون أي عواقب حقيقية.

لا أرى حجة pidfiles على أنها مماثلة لأن السجلات ليست مهمة حرجة ، ولكن PIDs كذلك. لا يمكنك تشغيل العمليات على الإطلاق بدون إنشاء PID ، ولكن يمكنك تشغيل أي تطبيق بدون إنشاء سجلات.

لا أعتقد أن أي شخص هنا يجادل ضد السلوك العام بسرعة الفشل هنا: بدلاً من ذلك ، نشير إلى أن السلوك الحالي السريع للفشل لملفات السجل هو نمط تصميم سيء. لكن يبدو لي أن هناك حلًا بسيطًا: تضمين معلمة تكوين تسمى "إنشاء دليل السجل تلقائيًا إذا لم يكن موجودًا؟" وعند التعيين على true ، اجعله ينفذ mkdir -p (كما يقترح @ dmitry-akimov-dXgjvQjNiMuVYecJ) بنفس الأذونات / الملكية مثل ملف السجل الذي تم إنشاؤه ، ثم انتقل إلى. يمكنك جعل معلمة التكوين الافتراضية "خطأ" بحيث يتم معالجة الخطأ في المرة الأولى التي يتم فيها تمرير دليل سجل غير موجود ، لذلك يضطر المستخدم إلى إلقاء نظرة فاحصة على تكوين السجل قبل اتخاذ قرار.

لا أجد الحجج المضادة ضد إنشاء الدليل التلقائي مقنعة للغاية.

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

لكن يبدو لي أن هناك حلًا بسيطًا: تضمين معلمة تكوين تسمى "إنشاء دليل السجل تلقائيًا إذا لم يكن موجودًا؟"

هذه القضية مفتوحة حاليا. أعدت فتحه لأنني أعتقد أنه يستحق إعادة النظر فيه. من الممكن أن نضيف نوعًا من الميزات الاختيارية لإنشاء أدلة. ذكرت هذا أعلاه أيضا. أنا أعمل حاليًا على قضايا أخرى ولا يمكنني العمل على هذه المشكلة بالذات في الوقت الحالي. قد يكون الملتزمون الآخرون بهذا المشروع على استعداد للعمل عليه ، أو يمكنهم أن يظلوا مفتوحين.

لم أر هذا منذ عامين ، لكنه بدأ في الظهور بشكل عشوائي مرة أخرى.

$ sudo supervisord -c /etc/supervisor/supervisord.conf
Error: The directory named as part of the path /var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log) does not exist
For help, use /usr/local/bin/supervisord -h

لقد تأكدت من وجود ملف /var/log/supervisor/supervisord.log ومنحت أذونات لـ 777 للاختبار ، وما زال يحدث. أيه أفكار؟

sdanbury هذه التذكرة عبارة عن طلب لإضافة خيار لإنشاء دليل لملفات السجل. مشكلتك مختلفة لأنك أنشأت الدليل بالفعل. لقد فتحت # 1229 لذلك.

+1

+1

يا له من خطأ غبي ولم يتم إصلاحه بعد. دليلنا /var/log عبارة عن tmpfs ، لذا تم مسحه تمامًا بين عمليات إعادة التشغيل.

لا أفهم حقًا سبب وجود الكثير من المعارضة لهذه الفكرة. Tbh أعتقد أن هذا السلوك يجب أن يكون متاحًا ومُفعَّلًا بشكل افتراضي للسجلات (لكني أتفهم القلق بشأن تغيير السلوك الافتراضي). لا أرى أي جدال حول إتاحته وتعطيله بشكل افتراضي.

إذا حصلت على دقيقة ، فقد أفكر في تقديم طلب سحب ، ولكن في حالة رغبة شخص آخر في معرفة ذلك:

هذا هو المكان الذي يخطئون فيه إذا لم يكن الدليل موجودًا
https://github.com/Supervisor/supervisor/blob/b6b762d809e8c5966208b0836a9403294c3294c4/supervisor/datatypes.py#L94 -L105
https://github.com/Supervisor/supervisor/blob/b6b762d809e8c5966208b0836a9403294c3294c4/supervisor/datatypes.py#L342 -L351

لذلك يمكن أن تكون بداية الإصلاح:

# https://github.com/Supervisor/supervisor/blob/3e7c082a71fef3860ecf06727edd091ddb3cc282/supervisor/options.py#L635
self.create_log_directories = boolean(
    get('supervisord', 'create_log_directories', 'true')) # +++
...
section.logfile = existing_dirpath(
    get('logfile', 'supervisord.log'), 
    create=self.create_log_directories) # +-

# https://github.com/Supervisor/supervisor/blob/b6b762d809e8c5966208b0836a9403294c3294c4/supervisor/datatypes.py#L342
def existing_dirpath(v, create=False):
    nv = os.path.expanduser(v)
    dir = os.path.dirname(nv)
    if not dir:
        # relative pathname with no directory component
        return nv
    if create: # +++
        os.makedirs(dir, exist_ok=True)
    if os.path.isdir(dir):
        return nv
    raise ValueError('The directory named as part of the path %s '
                     'does not exist' % v)

# https://github.com/Supervisor/supervisor/blob/b6b762d809e8c5966208b0836a9403294c3294c4/supervisor/datatypes.py#L94
def logfile_name(val, create=False):
    coerced = val.lower() if hasattr(val, 'lower') else val

    if coerced in LOGFILE_NONES:
        return None
    elif coerced in LOGFILE_AUTOS:
        return Automatic
    return existing_dirpath(val, create=create) # +-

# https://github.com/Supervisor/supervisor/blob/3e7c082a71fef3860ecf06727edd091ddb3cc282/supervisor/options.py#L970
lf_val = logfile_name(lf_val, create=self.create_log_directories) # +-

# https://github.com/Supervisor/supervisor/blob/3e7c082a71fef3860ecf06727edd091ddb3cc282/supervisor/options.py#L426
self.add("logfile", "supervisord.logfile", "l:", "logfile=",
         lambda v: existing_dirpath(v, create=self.create_log_directories),
         default="supervisord.log")

لقد قمت بإنشاء مسار السجل بنفسي
لكن المشرف لا ينشئ ملف السجل

~~ مساعدة

Tbh أعتقد أن هذا السلوك يجب أن يكون متاحًا ومُفعَّلًا بشكل افتراضي للسجلات (لكني أتفهم القلق بشأن تغيير السلوك الافتراضي). لا أرى أي جدال حول إتاحته وتعطيله بشكل افتراضي.

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

ظل هذا الموضوع صامتًا لمدة دقيقة ، ولكن نظرًا لأن القضية لا تزال مفتوحة ، أفترض أن التعليقات لا تزال موضع ترحيب.

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

الاقتراح الذي قدمه @ willmcgugan هو اقتراح جيد في رأيي ؛ لا يغير أي سلوكيات حالية أو افتراضية ، لذا فهو متوافق مع أي ملفات تكوين قد تكون موجودة اليوم. لست متأكدًا مما إذا كنت أعتقد أنه يجب أن يكون هناك خيار تكراري أو ما إذا كان يجب أن يفترض ببساطة mkdir -p إذا كان ينشئ أدلة. أنا أميل إلى الأخير.
يمكن تعيين الملكية للمستخدم: مجموعة تعمل عملية التسجيل على أساسها ، سواء كان ذلك المشرف نفسه أو طفلًا. أعتقد أن توثيق الأدلة التي تم إنشاؤها سيكون لها 775 أو 755 إذنًا سيكون كافياً.

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

كل ذلك ليقوله - تصويت متأخر آخر لصالح هذه الميزة.