Насколько я могу судить, никаких изменений, связанных с этим, между 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 Похоже, это не связано с этой ошибкой. В сообщениях от supervisorctl говорится, что он не может подключиться к supervisord. Вам нужно будет проверить журнал супервизора, чтобы узнать, что произошло. Вы также можете запустить его на переднем плане ( supervisord -n ) и посмотреть, завершится ли он во время перезагрузки.

@mnaberez Спасибо за совет по отладке. Я не уверен, почему вы думаете, что то, что я вижу, отличается от того, что первоначально сообщил jbrehm. Они кажутся мне идентичными. Я с радостью открою новую ошибку по этому поводу, если вы объясните, почему случаи разные, но я не вижу причин для этого.

Если я запустил supervisord на переднем плане, как вы посоветовали, запуск supervisorctl reload вызовет сбой supervisord с этим:

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.

Я не уверен, почему вы думаете, что то, что я вижу, отличается от того, что первоначально сообщил jbrehm.

Я мог ошибаться, но я интерпретировал исходный отчет как программу, работающую под супервизором, не перезапускается, а не как то, что супервизор дает сбой.

и проблема исчезнет, ​​если я вернусь к 3.0a10.

Спасибо за обратную трассировку и эту дополнительную информацию. Об этом же падении было сообщено в №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

У меня тоже такая проблема. Supervisord вылетает при вызове перезагрузки. Единственное решение - вернуться на 3.0a10?

@landreville Ошибка появилась в версии 3.0b1. Если вы собираетесь перейти на более раннюю версию, вам, вероятно, понадобится предыдущая версия, которая была 3.0a12.

+1 за эту проблему

то же самое с отправкой sighup

supervisord -n -u никто -c ../conf/supervisor.ini --pid = / tmp / supervisor.pid
2012-12-17 16: 08: 20,208 CRIT Установить uid пользователю 65534
2012-12-17 16: 08: 20,211 INFO supervisord запущен с pid 5016
2012-12-17 16: 08: 21,215 Появился INFO: 'celeryd' с pid 5019
2012-12-17 16: 08: 31,556 Успех ИНФОРМАЦИИ: celeryd вошел в состояние РАБОТА, процесс не работал более 10 секунд (startsecs)
2012-12-17 16: 08: 34,444 ПРЕДУПРЕЖДЕНИЕ получено SIGHUP, указывающее на запрос перезапуска
2012-12-17 16: 08: 34,444 ИНФОРМАЦИЯ в ожидании смерти сельдерея
2012-12-17 16: 08: 34,582 Информация остановлена: сельдерей (статус выхода 0)
Отслеживание (последний вызов последний):
Файл "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/loggers.py", строка 81, в emit
self.stream.write (сообщение)
ValueError: операция ввода-вывода для закрытого файла
Отслеживание (последний вызов последний):
Файл "/ var / www / configtest / env / bin / supervisord", строка 8, в
load_entry_point ('супервизор == 3.0b1', 'console_scripts', 'супервизор') ()
Файл "/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, на ходу
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 (сообщение)
Файл "/var/www/configtest/env/lib/python2.7/site-packages/supervisor/loggers.py", строка 313, критический
self.log (LevelsByName.CRIT, сообщение, ** кВт)
Файл "/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, в emit
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
Python 2.7.3

Все еще существует на supervisor == 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 Я лучше постараюсь не запускать его от имени пользователя root.

@aneumeier хорошо назначает пользователю разрешения на использование этой службы.

@ harph
У меня это сработало - большое спасибо!

@harph Я не могу согласиться - если пользователь может _запустить_ службу, почему он не может _перезапустить_ службу?

@aneumeier Я этого не говорил. Я сказал, что вы должны запустить службу перед ее перезагрузкой. Я сделал это с помощью sudo в примере, но если вы назначите пользователю правильные разрешения, он сможет запускать и перезапускать службу.

для меня запуск супервизора sudo работает хорошо :) Ubuntu 12.04 LTS

запуск супервизора службы sudo
У меня тоже сработало - большое спасибо!

@harph +1

: +1:
Сегодня я удалил Supervisor из репозитория CentOS и установил его с помощью easy_install. supervisord работает лучше, чем когда-либо. но у меня также есть проблема с 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.08.2014 17:00 Этай Коэн-Солал написал:

Я удалил сегодня Supervisor из репозитория CentOS и установил его с помощью
easy_install. supervisord работает лучше, чем когда-либо. но у меня также есть
проблема с supervisorctl.

Supervisorctl требуется доступ к supervisord.conf в пользовательской конфигурации.
Supervisorctl ищет файлы supervisord.conf в следующих
локации (в таком порядке):

и т.д. / supervisord.conf
supervisord.conf
/etc/supervisord.conf

Пытаться:

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

Для меня | начало службы супервайзера | решение не работает. также пытаюсь
| перезапуск супервизора службы | затем старт, стоп, старт ... дальше и
офф..перезапуск .. ничего.

| $ supervisorctl reload
ошибка:, [Errno 2] Нет такого файла или каталога: file:линия 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

И файла действительно нет. Supervisord работает, а все демоны подключены к сети и работают.

18.08.2014 17:48 Этай Коэн-Солал написал:

[включают]
files = /var/www/websites/supervisor/*.conf
|

Запускаем команду:

| # supervisorctl -c /etc/supervisord.conf
unix: ///var/tmp/supervisor.sock такого файла нет
|

И файла действительно нет. Супервайзер работает и все демоны
онлайн и работают.

Значит, Supervisord не был запущен с использованием этого файла конфигурации. Ты
таким же образом можно запустить supervisord с этим файлом конфигурации:

supervisord -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

Еще раз спасибо. Вы хотите, чтобы я снова отправил сообщение почтовой рассылке? хотя это похоже на некоторые ошибки, о которых здесь сообщали другие.

Это совершенно не связано с исходным постом, так что да.

Но в любом случае, раз уж мы его так сильно загрязнили, попробуйте:

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.08.2014 18:09 Этай Коэн-Солал написал:

Спасибо.

| # supervisord -c /etc/supervisord.conf

supervisorctl -c /etc/supervisord.conf перезагрузить

ошибка:, [Errno 2] Нет такого файла или каталога: file:линия 1

supervisorctl -c /etc/supervisord.conf перезапустить foo

unix: ///var/tmp/supervisor.sock такого файла нет

Я также пытался найти supervisor.sock

Понятия не имею. Давайте определенно перестанем об этом говорить здесь. Я бы предложил
Отнесу его к почтовому отправителю.

• C

Я столкнулся с той же проблемой, что и @ ET-CS
не могу найти файл sock
использование vagrant для запуска 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 и перезапустил

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.

Шич показал проблему с логированием. На самом деле я удаляю * из / var / log / примерно день назад ..
воссоздан и после еще одного sudo supervisord , все хорошо.

Спасибо @ JayH5, это сработало для меня

У меня была такая же проблема с файлом .sock, который не найден. Предложения @mistermoe помогли мне решить проблему.

$ sudo supervisorctl перезагрузка
ошибка:, [Errno 2] Нет такого файла или каталога: file: /usr/lib/python2.7/socket.py строка: 224
Статус $ sodu supervisorctl
unix: ///var/run/supervisor.sock такого файла нет

После перезапуска supervisorctl эта проблема решена!

изменять
[супервайзер]
;;;;;; http_port = / var / tmp / supervisor.sock; (по умолчанию запускается сервер сокетов домена UNIX)
http_port = 127.0.0.1: 9001; (в качестве альтернативы ip_address: port указывает AF_INET)

к
[супервайзер]
http_port = / var / tmp / supervisor.sock; (по умолчанию запускается сервер сокетов домена UNIX)
;;;;;; http_port = 127.0.0.1: 9001; (в качестве альтернативы ip_address: port указывает 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 строка: 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. Убедитесь, что supervisord запущен. Используйте диспетчер служб вашей ОС (start, /etc/init.d, service и т. Д.), Чтобы запустить его.
2. Затем перезагрузите supervisorctl.

supervisorctl обращается к демону супервизора. Если демон не существует, этот инструмент ничего не может дать инструкциям. Когда он пытается подключиться, он не может найти файл сокета

Это была проблема, которая время от времени беспокоила нас на некоторых из наших старых серверов. Для rhel / centos проверьте этот отчет об 3.0-1.el7 помещает файл sock в /var/tmp/supervisor.sock , который очищается через 30 дней. Вот почему для нас проблема возникала периодически. Исправлено этой фиксацией в выпуске 3.1.3 .

@harph Спасибо!
sudo service supervisord start
работает нормально!

Этот комментарий мне очень помогает, @efusionsoft , спасибо.

Но у меня есть некоторые улучшения для вашего решения.
1) Когда я запустил supervisor с конфигурацией efusionsoft, у меня появилась ошибка:

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

Если у вас такая же ошибка - добавьте этот код после раздела [supervisor]:

[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

Почему бы не добавить соответствующее сообщение об ошибке, что supervisord не запущен вместо:

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 журнал показал, что проблема исходила из старой службы, которую супервизор пытался запустить, но я удалил эту программную папку некоторое время назад, но не из конфигурации супервизора. / папка. поэтому он пытался запустить несуществующую программу, и это вызывало проблему.