Problem z błędem gniazda administratora [zamknięty]

99

$ supervisorctl reread
error: <class 'socket.error'>, [Errno 111] Connection refused: file: /usr/lib64/python2.6/socket.py line: 567

Próbuję skonfigurować nadzorcę w moim systemie produkcyjnym, ale napotykam ten błąd. Plik dziennika nadzorcy jest pusty.

Kiedy po prostu piszę supervisorctl, narzeka:

http://localhost:9001 refused connection

Obecnie nic nie nasłuchuje na porcie 9001, AFACT: lsof | grep TCPnic nie zwraca.

supervisord

— kelorek
źródło

172

Musisz uruchomić supervisord, zanim będzie można używać supervisorctl. W moim przypadku:

sudo supervisord -c /etc/supervisor/supervisord.conf
sudo supervisorctl -c /etc/supervisor/supervisord.conf

— kelorek
źródło

2

Nie powinieneś musieć sudo supervisorctl, ale napotkałem problemy z uprawnieniami, które spowodowały, że zrezygnowałem z rozwiązania tego problemu

— kelorek

1

Mam taki sam wydany jak kelorek ale powyższa komenda na mnie nie zadziałała.

— Charlesliam,

Co wraca po naciśnięciu Enter?

— kelorek

5

192.168.111.100:9001 odmówił połączenia

— Charlesliam

Wspaniały człowieku, mój przełożony biegał po latach!

— Jaimin

37

Jeśli zacząłeś nadzorować z niestandardową ścieżką, na przykład:

sudo supervisord -c /mypath/supervisord.conf

Następnie powinieneś również uruchomić supervisorctl z tym samym parametrem, na przykład:

sudo supervisorctl -c /mypath/supervisord.conf

— Jonathan
źródło

2

to naprawdę mi pomogło

— Justin M. Ucar

12

Możesz uzyskać ten problem, jeśli uruchomisz nadzorcę z względnym adresem URL dla, -ca następnie spróbujesz uruchomić supervisorctl z innego katalogu.

Na przykład:

supervisord -c supervisord.conf
supervisorctl start someapp ## works 
cd somedirectory
supervisorctl restart someapp ## http://localhost:9001 refused connection

Rozwiązaniem byłoby zawsze używać ścieżki bezwzględnej. na przykład:

Dobry:

supervisord -c /etc/supervisor/supervisord.conf

Zły:

supervisord -c supervisord.conf

— toast38coza
źródło

5

Ten problem występuje również, gdy supervisord.confużywana jest stara wersja pliku. Nowsza wersja nadzorcy używa innego pliku konfiguracyjnego. Powyższe rozwiązania nie działają. W takim przypadku wystarczy ponownie wygenerować plik konfiguracyjny za pomocą

echo_supervisord_conf > /etc/supervisord.conf

Mam nadzieję, że to komuś pomoże.

— Krishna Deepak
źródło

3

wykonaj następujące czynności:

sudo service supervisor start

post w którym wszystko jest normalne jak b4 - jest problem z wersją 1b

sudo supervisorctl reload

— VKB
źródło

2

W Ubuntu 18.04 z pakietem dystrybucyjnym

Prawdopodobnie zrobiłeś ten sam błąd, co ja, tworząc plik konfiguracyjny, /etc/supervisord.confpodczas gdy mój menedżer usług ( systemd ) używał tego pliku konfiguracyjnego/etc/supervisor/supervisord.conf

sudo rm /etc/supervisord.conf

Lub

sudo mv /etc/supervisord.conf /etc/supervisor/supervisord.conf

jeśli chcesz to zatrzymać

Teraz możesz biec sudo supervisorctl

Czemu?

po uruchomieniu supervisorctlnajpierw wyszukuje plik konfiguracyjny znajdujący się pod adresem /etc/supervisord.conf, jeśli go nie ma, wyszuka domyślny plik pakietu, /etc/supervisor/supervisord.confto jest ten, który faktycznie działa systemd .

Systemd zawsze używa tego pliku, /etc/supervisor/supervisord.confniezależnie od istnienia innego pliku.

Możesz sprawdzić, który plik używa systemd , uruchamiającsudo systemctl status supervisor

Możesz zobaczyć w ostatnim wierszu polecenie, w którym plik konfiguracyjny jest zakodowany na stałe

— Madacol
źródło

-1

oba supervisordi supervisorctlużywaj -cz absolutną ścieżką do pliku konfiguracyjnego, upewnij się, że oba polecenia uruchamiają się z tą samą konfiguracją.

— zhengquan
źródło