لم تكن هناك تغييرات تتعلق بهذا بين 3.0a10 و 3.0a12 بقدر ما أستطيع أن أقول. هل تم تكوين autostart=true للبرنامج؟

في Ubuntu10.04 ، يتسبب supervisorctl reload في فشل عملية المشرف. المحاولات اللاحقة لتشغيل النتيجة supervisorctl في

unix:///var/run/supervisor.sock no such file

أو أكثر غموضا

error: <class 'socket.error'>, [Errno 2] No such file or directory: file: <string> line: 1

يجب إعادة تشغيل عملية المشرف يدويًا sudo supervisord .

هذا حقا سيء.

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

mnaberez شكرا

إذا قمت بتشغيل المشرف في المقدمة كما نصحت ، فإن تشغيل supervisorctl reload يتسبب في تعطل المشرف مع هذا:

Traceback (most recent call last):
  File "/usr/local/lib/python2.6/dist-packages/supervisor/loggers.py", line 81, in emit
    self.stream.write(msg)
ValueError: I/O operation on closed file
Traceback (most recent call last):
  File "/usr/local/bin/supervisord", line 9, in <module>
    load_entry_point('supervisor==3.0b1', 'console_scripts', 'supervisord')()
  File "/usr/local/lib/python2.6/dist-packages/supervisor/supervisord.py", line 360, in main
    go(options)
  File "/usr/local/lib/python2.6/dist-packages/supervisor/supervisord.py", line 370, in go
    d.main()
  File "/usr/local/lib/python2.6/dist-packages/supervisor/supervisord.py", line 77, in main
    info_messages)
  File "/usr/local/lib/python2.6/dist-packages/supervisor/options.py", line 1274, in make_logger
    self.logger.critical(msg)
  File "/usr/local/lib/python2.6/dist-packages/supervisor/loggers.py", line 313, in critical
    self.log(LevelsByName.CRIT, msg, **kw)
  File "/usr/local/lib/python2.6/dist-packages/supervisor/loggers.py", line 319, in log
    handler.emit(record)
  File "/usr/local/lib/python2.6/dist-packages/supervisor/loggers.py", line 214, in emit
    self.doRollover()
  File "/usr/local/lib/python2.6/dist-packages/supervisor/loggers.py", line 223, in doRollover
    if not (self.stream.tell() >= self.maxBytes):
ValueError: I/O operation on closed file

أنا أقوم بتشغيل 3.0b1 إذا كان ذلك مهمًا.

... وتختفي المشكلة إذا عدت إلى الإصدار 3.0a10.

لست متأكدًا من سبب اعتقادك أن ما أراه يختلف عما ذكره جبريهم في الأصل.

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

وتختفي المشكلة إذا عدت إلى الإصدار 3.0a10.

شكرا على backtrace وهذه المعلومات الإضافية. تم الإبلاغ عن هذا الحادث نفسه في # 130. يبدو أننا قدمنا ​​هذا الخطأ في d2bc68561f96b3d8d523c751879429ead8e87894.

لدي نفس المشكلة.

إليك جلسة نموذجية:

$ sudo supervisorctl -c conf/supervisord.conf reload
Restarted supervisord
$ sudo supervisorctl -c conf/supervisord.conf status
unix:///tmp/supervisord.sock no such file

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

landreville تم تقديم الخطأ في 3.0b1. إذا كنت تنوي الرجوع إلى إصدار أقدم ، فربما تريد الإصدار السابق ، والذي كان 3.0a12.

+1 لهذه المشكلة

نفس الشيء مع إرسال التنهد

المشرف -n -u nobody -c ../conf/supervisor.ini --pid = / tmp / supervisor.pid
2012-12-17 16: 08: 20،208 CRIT تعيين uid للمستخدم 65534
2012-12-17 16:08: 20211 بدأ مشرف المعلومات بـ pid 5016
2012-12-17 16:08: 21،215 انتشار معلومات: 'celeryd' with pid 5019
2012-12-17 16: 08: 31،556 نجاح المعلومات: دخل الكرفس في حالة التشغيل ، وبقيت العملية مستمرة لمدة تزيد عن 10 ثوانٍ (ثوانٍ)
2012-12-17 16: 08: 34،444 تلقى WARN SIGHUP يشير إلى طلب إعادة التشغيل
2012-12-17 16: 08: 34،444 معلومة تنتظر موت الكرفس
2012-12-17 16:08: 34،582 توقف INFO: celeryd (حالة الخروج 0)
Traceback (آخر مكالمة أخيرة):
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/loggers.py" ، السطر 81 ، في الإصدار
self.stream.write (رسالة)
ValueError: عملية الإدخال / الإخراج في ملف مغلق
Traceback (آخر مكالمة أخيرة):
ملف "/ var / www / configtest / env / bin / supervisord" ، السطر 8 ، بتنسيق
load_entry_point ('Supervisor == 3.0b1'، 'console_scripts'، 'supervisord') ()
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/supervisord.py" ، سطر 360 ، بشكل رئيسي
اذهب (خيارات)
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/supervisord.py" ، السطر 370 ، في go
d.main ()
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/supervisord.py" ، السطر 77 ، بشكل رئيسي
info_messages)
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/options.py" ، السطر 1274 ، في make_logger
self.logger.critical (msg)
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/loggers.py" ، السطر 313 ، في حالة حرجة
self.log (LevelsByName.CRIT، msg، ** kw)
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/loggers.py" ، السطر 319 ، في السجل
handler.emit (سجل)
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/loggers.py" ، السطر 214 ، في الإصدار
self.doRollover ()
ملف "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/loggers.py" ، السطر 223 ، في doRollover
إن لم يكن (self.stream.tell ()> = self.maxBytes):
ValueError: عملية الإدخال / الإخراج في ملف مغلق

ثابت في 25303d45eb75c980e97a5ea3eca307a464ad8e2b.

على أي حال للتعافي في هذه الحالة؟

فهل من الصحيح حقًا إعادة تحميل ملفات التكوين على إصدارات أقدم مما كانت عليه قبل شهر
أتركك في حالة توقف فيها المشرف عن العمل؟

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

على أي حال للتعافي في هذه الحالة؟

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

لم يقم الإصلاح 25303d4 بإصلاح هذه المشكلة بالفعل بالنسبة لي. نفس الخطأ.

ألغيت تعليقي الأخير. أنا قادر على إعادة التحميل الآن بدون خطأ المقبس باستخدام master (3.0b2-dev). يبدو أن المشكلة الأخيرة قد نتجت عن مشرف جديد يؤمن أن عمليته لن تبدأ عند إعادة تحميل المشرف. تسبب ذلك في نفس الخطأ في مقبس unix الذي يبدو ، وبالتالي طردني ، ولكن بمجرد أن يتم إصلاح العملية ، تبدأ عمليات إعادة التحميل في العمل.

هذا الخطأ لا يزال موجودا.

الخطأ موجود بالنسبة لي أيضًا.

على supervisorctl reload

يقول ملف السجل:

2013-06-01 13:58:54,697 INFO waiting for memmon, celerydb, celerycam, gunicorn to die
2013-06-01 13:58:54,698 INFO stopped: celerycam (terminated by SIGTERM)
2013-06-01 13:58:54,868 INFO stopped: gunicorn (exit status 0)
2013-06-01 13:58:54,871 INFO stopped: celerydb (exit status 0)
2013-06-01 13:58:54,871 INFO stopped: memmon (terminated by SIGTERM)

(لا مزيد من المدخلات)

المشرف موجود في virtualenv ، الإصدار هو supervisor==3.0b2
بايثون 2.7.3

لا يزال موجودًا على المشرف == 3.0b2 ، ربما تم إعادة تقديمه؟ قد يكون مرتبطًا بمقبس مخصص في ملف التكوين ، لا أعرف حقًا.

لقد استخدمنا supervisor==3.0b1 لنحو 6 أشهر الآن ولم نبدأ في مواجهة المشكلة الموضحة هنا إلا مؤخرًا. على وجه التحديد ، نستخدم Jenkins لأغراض البناء / النشر التي يقودها ملف النسيج. فيما يلي سجلات المشرف عند البدء:

2013-06-23 14:03:10,623 INFO daemonizing the supervisord process
2013-06-23 14:03:10,624 INFO supervisord started with pid 24211
2013-06-23 14:03:11,627 INFO spawned: 'websocket' with pid 24212
2013-06-23 14:03:11,628 WARN received SIGHUP indicating restart request
2013-06-23 14:03:11,628 INFO waiting for websocket to die
2013-06-23 14:03:15,051 INFO waiting for websocket to die
2013-06-23 14:03:18,674 INFO waiting for websocket to die
2013-06-23 14:03:21,678 WARN killing 'websocket' (24212) with SIGKILL
2013-06-23 14:03:21,678 INFO waiting for websocket to die
2013-06-23 14:03:21,685 INFO stopped: websocket (terminated by SIGKILL)

كما ترى ، مباشرة بعد عمليات الشيطنة والتكاثر ، يتلقى المشرف SIGHUP . لست متأكدًا تمامًا من أين يتم إرسال إشارة SIGHUP إلى عملية المشرف.

هل هذا ثابت مع 3.0.b2؟ التغيير هنا لا يشير إلى ذلك.

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

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

لقد قمت بحل هذه المشكلة ببدء الخدمة:

sudo service supervisord start

بعد ذلك يمكنك الجري:

sudo supervisorctl reload

harph سأحاول بدلاً من ذلك وتجنب تشغيله كجذر.

aneumeier حسنًا ، قم بتعيين أذونات للمستخدم لاتخاذ هذه الخدمة.

@ harph
عملت بالنسبة لي - شكرا جزيلا!

harph لا أستطيع الموافقة - عندما يستطيع المستخدم _بدء_ الخدمة ، لماذا لا يمكنه _ إعادة تشغيل الخدمة؟

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

بالنسبة لي ، يبدأ مشرف خدمة sudo يعمل بشكل جيد :) Ubuntu 12.04 LTS

بدء مشرف خدمة sudo
لقد نجحت أيضًا بالنسبة لي - شكرًا جزيلاً!

harph +1

: +1:
لقد قمت اليوم بإزالة Supervisor من مستودع CentOS وقمت بتثبيته باستخدام easy_install. المشرف يعمل بشكل أفضل من أي وقت مضى. لكن لدي أيضًا مشكلة مع Supervisorctl.

بالنسبة لي service supervisor start الحل لا يعمل. حاول أيضًا service supervisor restart ثم ابدأ ، توقف ، ابدأ ... تشغيل وإيقاف .. ابدأ .. لا شيء.

$ supervisorctl reload
error: <class 'socket.error'>, [Errno 2] No such file or directory: file: <string> line: 1
$ supervisorctl restart foo
unix:///var/tmp/supervisor.sock no such file

Supervisor-3.1.1-py2.6 في إصدار CentOS 6.5 (نهائي)

في 18/8/2014 05:00 مساءً ، كتب إيتاي كوهين-سولال:

لقد قمت اليوم بإزالة Supervisor من مستودع CentOS وقمت بالتثبيت باستخدام
تثبيت سهل. المشرف يعمل بشكل أفضل من أي وقت مضى. ولكن لدي أيضًا
مشكلة مع المشرف ctl.

يحتاج Supervisorctl الوصول إلى supervisord.conf في التكوين المخصص.
يبحث Supervisorctl عن ملفات supervisord.conf فيما يلي
المواقع (بهذا الترتيب):

إلخ / supervisord.conf
المشرف
/etc/supervisord.conf

يحاول:

Supervisorctl -c /path/to/the/supervisorctl.conf

بالنسبة لي | بدء مشرف الخدمة | الحل لا يعمل. يحاول أيضا
| إعادة تشغيل مشرف الخدمة | ثم ابدأ ، توقف ، ابدأ ... في و
قبالة .. ابدأ .. لا شيء.

| إعادة تحميل $ supervisorctl
خطأ:، [Errno 2] لا يوجد مثل هذا الملف أو الدليل: ملف:خط 1
$ Supervisorctl إعادة تشغيل myapp
unix: ///var/tmp/supervisor.sock لا يوجد مثل هذا الملف
|

Supervisor-3.1.1-py2.6 في إصدار CentOS 6.5 (نهائي)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Supervisor/supervisor/issues/121#issuecomment -52554399.

شكرا لك.
الملف موجود في /etc/supervisord.conf

[supervisord]
http_port=/var/tmp/supervisor.sock ; (default is to run a UNIX domain socket server)
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB       ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=10          ; (num of main logfile rotation backups;default 10)
loglevel=debug              ; (logging level;default info; others: debug,warn)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
minfds=1024                 ; (min. avail startup file descriptors;default 1024)
minprocs=200                ; (min. avail process descriptors;default 200)
user=root                   ; (default is current user, required if root)

[supervisorctl]
serverurl=unix:///var/tmp/supervisor.sock ; use a unix:// URL  for a unix socket
username=root               ; should be same as http_username if set
password=[mypassword]       ; should be same as http_password if set

[include]
files = /var/www/websites/supervisor/*.conf

تشغيل الأمر:

# supervisorctl -c /etc/supervisord.conf
unix:///var/tmp/supervisor.sock no such file

والملف ليس هناك بالفعل. يعمل المشرف وجميع الشياطين على الإنترنت وتعمل.

في 18/8/2014 05:48 مساءً ، كتب إيتاي كوهين-سولال:

[تضمن]
الملفات = /var/www/websites/supervisor/*.conf
|

تشغيل الأمر:

| # Supervisorctl -c /etc/supervisord.conf
unix: ///var/tmp/supervisor.sock لا يوجد مثل هذا الملف
|

والملف ليس هناك بالفعل. الاشراف يعمل وجميع الشياطين
متصلون بالإنترنت ويعملون.

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

المشرف -c /etc/supervisord.conf

يجب أن نأخذ هذا إلى العامل ، لم أدرك أننا لم نكن فيه ..
هذا بعيد جدًا عن تقرير خطأ OP.

يجب أن يتم تحميل ملف التكوين لسببين:
إنه الملف الوحيد الذي أملكه

locate supervisord.conf
/etc/supervisord.conf
/etc/supervisord.conf.backup
/etc/supervisord.conf.rpmsave

1. يعمل التضمين من /var/www/websites/supervisor/*.conf ، ولا توجد فرصة لتعيين هذا المجلد في ملف افتراضي أو قديم آخر لأنني قمت فقط بتعيينه في هذا الملف اليوم.

لكن على أي حال ، لقد حاولت:

# service supervisord stop
Shutting down supervisord:                                 [  OK  ]
# supervisord -c /etc/supervisord.conf
# supervisorctl reload
error: <class 'socket.error'>, [Errno 2] No such file or directory: file: <string> line: 1
# supervisorctl restart foo
unix:///var/tmp/supervisor.sock no such file

شكرا مرة اخرى. هل تريد مني أن أنشر مرة أخرى إلى maillist؟ على الرغم من أنه مشابه لبعض الأخطاء التي أبلغ عنها الآخرون هنا.

إنه غير مرتبط تمامًا بالمنشور الأصلي ، لذا نعم.

لكن على أي حال ، نظرًا لأننا قمنا بتلويثه حتى الآن ، حاول:

supervisord -c /etc/supervisord.conf
supervisorctl -c /etc/supervisord.conf reload
supervisorctl -c /etc/supervisord.conf restart foo

شكرا لك.

# supervisord -c /etc/supervisord.conf
# supervisorctl -c /etc/supervisord.conf reload
error: <class 'socket.error'>, [Errno 2] No such file or directory: file: <string> line: 1
# supervisorctl -c /etc/supervisord.conf restart foo
unix:///var/tmp/supervisor.sock no such file

لقد حاولت أيضًا تحديد موقع supervisor.sock

# updatedb
# locate supervisor.sock
# 

لايوجد ملف مشابه.

في 18/8/2014 06:09 مساءً ، كتب إيتاي كوهين-سولال:

شكرا لك.

| # المشرف -c /etc/supervisord.conf

Supervisorctl -c /etc/supervisord.conf إعادة تحميل

خطأ:، [Errno 2] لا يوجد مثل هذا الملف أو الدليل: ملف:خط 1

Supervisorctl -c /etc/supervisord.conf إعادة تشغيل foo

unix: ///var/tmp/supervisor.sock لا يوجد مثل هذا الملف

لقد حاولت أيضًا تحديد موقع supervisor.sock

لا دليل. دعنا نتوقف بالتأكيد عن الحديث عن هذا هنا. أود أن أقترح
أخذه إلى المختبر.

• ج

أواجه نفس المشكلة مثل @ ET-CS
لا يمكن العثور على ملف جورب
باستخدام المتشرد لتدوير ubuntu vm

واستخدام

إضافة دعم المشرف

sudo supervisord -c /vagrant/scripts/supervisord.conf

أحصل على نفس الأخطاء كما هو مذكور أعلاه .. جورب مفقود

نفس المشكلة لـ 3.0b2 في ubuntu 14.04 ، لن يتم إصلاح إعادة التشغيل

error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 224

لقد وجدت السبب:

stdout_logfile_maxbytes=100M

يجب ان يكون

stdout_logfile_maxbytes=100MB

كان لي مشكلة مشابهة.
كانت مشكلتي أن المسار إلى ملف السجل لم يتم إنشاؤه أو الوصول إليه.

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

supervisord -c /path/to/supervisord.conf

وواجه الخطأ التالي

Error: Another program is already listening on a port that one of our HTTP servers is configured to use.  Shut this program down first before starting supervisord.

لذلك حذف مقبس المشرف في / var / run و reran

supervisord -c /path/to/supervisord.conf

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

harph العمل الجيد! إنه مفيد بالنسبة لي! شكرا!

ما عليك سوى تشغيل supervisorctl -c /etc/supervisor/supervisord.conf
لا يمكن لـ supervisorctl العثور على ملف التكوين

supervisord -n ساعدني في العثور على معلومات الخطأ التفصيلية ، شكرًا.

حصلت على

unix:///var/run/supervisor.sock no such file

خطأ عند محاولة الوصول إلى supervisorctl. لحل هذه المشكلة ، عليك التأكد من أن خدمة المشرف تعمل:

sudo service supervisor status

سيخبرك إذا كانت هذه هي مشكلتك ، وإذا فهمت أنها لا تعمل ، فما عليك سوى البدء بها

sudo service supervisor start

لقد وجدت أنه عند تشغيل المشرف في Vagrant VM ، لن يتم تشغيل الخدمة تلقائيًا لسبب ما ، مما يستلزم بدء خدمة يدوية.

وجدت هذا الخطأ أيضًا على raspberry pi مع تحديث Weesy.

sudo supervisorctl reload
error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 224

القراءة أعلاه فعلت:

sudo supervisord
Error: The directory named as part of the path /var/log/supervisor/supervisord.log does not exist.

أظهر Shich مشكلة في التسجيل. بالفعل أقوم بإزالة * من / var / log / يوم أو مرة أخرى ..
إعادة إنشائه وبعد sudo supervisord ، كل شيء جيد.

شكرا @ JayH5 لقد عملت بالنسبة لي

كان لدي نفس المشكلة من ملف .sock غير موجود. ساعدتني اقتراحات

إعادة تحميل $ sudo Supervisorctl
خطأ:، [Errno 2] لا يوجد مثل هذا الملف أو الدليل: file: /usr/lib/python2.7/socket.py line: 224
$ sodu Supervisorctl status
unix: ///var/run/supervisor.sock لا يوجد مثل هذا الملف

بعد إعادة تشغيل المشرف ، سيتم حل هذه المشكلة!

يتغير
[المشرف]
؛؛؛؛؛؛؛ http_port = / var / tmp / supervisor.sock ؛ (الافتراضي هو تشغيل خادم مقبس مجال UNIX)
http_port = 127.0.0.1: 9001 ، (بالتناوب ، ip_address: المنفذ يحدد AF_INET)

ل
[المشرف]
http_port = / var / tmp / supervisor.sock ؛ (الافتراضي هو تشغيل خادم مقبس مجال UNIX)
؛؛؛؛؛؛؛ http_port = 127.0.0.1: 9001 ؛ (بالتناوب ، ip_address: المنفذ يحدد AF_INET)

حل مشكلتي

إذا استمرت المشكلة لدى شخص ما:

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

[unix_http_server]
file = /tmp/supervisor.sock
chmod = 0777
chown= mywebsiteuser:mywebsiteusergroup


[supervisord]
logfile = /tmp/supervisord.log
logfile_maxbytes = 50MB
logfile_backups=10
loglevel = info
pidfile = /tmp/supervisord.pid
nodaemon = false
minfds = 1024
minprocs = 200
umask = 022
user = mywebsiteuser
identifier = supervisor
directory = /tmp
nocleanup = true
childlogdir = /tmp
strip_ansi = false

[supervisorctl]
##serverurl = unix:///tmp/supervisor.sock
serverurl = http://localhost:9001

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /home/mywebsiteuser/public_html/artisan queue:work database --sleep=3 --tries=3 --daemon
autostart=true
autorestart=true
user=mywebsiteuser
numprocs=8
redirect_stderr=true
stdout_logfile=/home/mywebsiteuser/worker.log

احفظ واخرج من المحرر.

ابحث عن عملية المشرف الحالية واقتلها

pgrep -fl supervisord

قم بتشغيل الأوامر التالية ويجب أن يكون العامل لديك قيد التشغيل

supervisord -c /etc/supervisord.conf
supervisorctl -c /etc/supervisord.conf reload
supervisorctl -c /etc/supervisord.conf start laravel-worker:*

شكرا omsobliga

أهلا يا أصدقاء!
لدي مشكلة كهذه.
لقد اتبعت هذا الرابط: https://serversforhackers.com/monitoring-processes-with-supervisord ، ولكن عندما أقوم بتشغيل هذا الأمر "supervisorctl reread" تظهر هذه الرسالة:
"خطأ:، [Errno 2] لا يوجد مثل هذا الملف أو الدليل: file: /usr/lib/python2.7/socket.py line: 228 "
ماذا يعني بالضبط؟
شكرا لك.

وجود هذه المشكلة باستخدام الدمية

Error: /Stage[main]/Supervisor/Service[supervisor]: Failed to call refresh: Could not restart Service[supervisor]: Execution of 'supervisorctl reload' returned 2: error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 224
Error: /Stage[main]/Supervisor/Service[supervisor]: Could not restart Service[supervisor]: Execution of 'supervisorctl reload' returned 2: error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 224

ربما هناك علاقة بين No such file or directory بهذه المشكلة؟

الحل هو

1. تأكد من تشغيل المشرف. استخدم مدير خدمة نظام التشغيل لديك (ابدأ ، /etc/init.d ، خدمة ، إلخ) لبدء تشغيله
2. ثم أعد التحميل من قبل المشرف ctl.

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

لقد كانت هذه مشكلة تزعجنا من وقت لآخر على بعض خوادمنا القديمة. بالنسبة إلى rhel / centos ، تحقق من تقرير الخطأ هذا. باختصار ، يقوم المشرف 3.0-1.el7 بإصدار ملف جورب عند /var/tmp/supervisor.sock ، والذي يتم تنظيفه بعد 30 يومًا. ولهذا السبب بدت القضية متقطعة بالنسبة لنا. تم إصلاحه من خلال هذا الالتزام في إصدار 3.1.3 .

harph شكرا!
sudo service supervisord start
أنه يعمل بشكل جيد!

هذا التعليق يساعدني كثيرًا ، efusionsoft ، شكرًا لك.

لكن لدي بعض التحسينات للحل الخاص بك.
1) عندما قمت بتشغيل المشرف مع تكوين efusionsoft ، حصلت على خطأ:

Please check that the [rpcinterface:supervisor] section is enabled in the configuration file (see sample.conf).

إذا كان لديك نفس الخطأ - أضف هذا الرمز بعد قسم [المشرف]:

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

2) serverurl = http: // localhost : 9001 لا يعمل معي ، وليس لدي أي فكرة عن السبب. لحسن الحظ ، serverurl = unix: ///tmp/supervisor.sock يعمل بشكل جيد بالنسبة لي.

ها هي النسخة الكاملة من /etc/supervisord.conf الخاص بي:

[unix_http_server]
file  = /tmp/supervisor.sock
chmod = 0777
chown = mywebsiteuser:mywebsiteusergroup

[supervisord]
logfile = /tmp/supervisord.log
logfile_maxbytes = 50MB
logfile_backups=10
loglevel = info
pidfile = /tmp/supervisord.pid
nodaemon = false
minfds = 1024
minprocs = 200
umask = 022
user = mywebsiteuser
identifier = supervisor
directory = /tmp
nocleanup = true
childlogdir = /tmp
strip_ansi = false

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl = unix:///tmp/supervisor.sock
##serverurl = http://127.0.0.1:9001

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php/home/mywebsiteuser/public_html/artisan queue:work database --sleep=3 --tries=3 --daemon
autostart=true
autorestart=true
user=mywebsiteuser
numprocs=1
redirect_stderr=true
stdout_logfile=/home/mywebsiteuser/worker.log

بعد حفظ التكوين:
1) ابحث عن جميع حالات المشرف قيد التشغيل:
pgrep -fl supervisord
2) قتل جميع عمليات المشرف الجارية
sudo kill {your process PID}
3) إطلاق المشرف مع التكوين الجديد:
supervisord -c /etc/supervisord.conf
4) تحقق من حالة المشرف
supervisorctl -c /etc/supervisord.conf status
5) استمتع!

هذا عمل لي

sudo systemctl start supervisor
sudo systemctl enable supervisor
sudo supervisorctl reload

لماذا لا تضيف رسالة خطأ مناسبة مفادها أن المشرف لا يعمل بدلاً من:

error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib64/python2.7/socket.py line: 224

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

هذه هي الطريقة التي حلت بها مشكلة unix:///tmp/supervisor.sock no such file على RHEL

ps -ef | grep supervisord # get supervisord PID
kill -s SIGTERM 1234 # where 1234 is the PID
ps -ef | grep supervisord # check that supervisord is killed
supervisord # restart the daemon

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