Supervisor: Python Error when running supervisorctl

What's in your supervisord.conf? Usually /etc/supervisor/supervisord.conf.

I'm going to close this due to lack of activity. If you're still having this issue and can provide more information, we can reopen.

I get the exact same error on a freshly installed supervisor with the default configuration file as output by echo_supervisord_conf. I installed the configuration file locally, and am running it as a regular user and not root:

$ supervisorctl
error: <class 'socket.error'>, [Errno 97] Address family not supported by protocol: file: /usr/lib/python2.7/socket.py line: 571
supervisor>

@bbirand if you execute supervisorctl -c /explicit/path/to/config/file/echoed/out/supervisord.conf do you get the same error? If so, can you include the contents of that file in a separate comment?

Yup, that fixed it. I didn't realize I had to pass the configuration file to the supervisorctl call as well, but of course it make sense.. Sorry for the wrong alarm.

(Although a more descriptive error message instead of the failed socket connection would be more helpful. I don't even have a /etc/supervisor.conf file, so I would have imagined supervisorctl would have failed with a "Configuration file not found" error or something.)

A specific "not found" error should be emitted if supervisord can't find a config file. In later versions, there's also a different "not readable" error if supervisord finds one but can't read it. When -c is not used to specify an explicit path to a config file, supervisord will search for one.

supervisorctl will also search for a config file. Before Supervisor 3.0b2, a config file was always required and it would give an error as described above. In 3.0b2 and later, supervisorctl can be used without a config file. In that case, the connection info should be given in command line options. I think if it can't find a config file, and you don't give the connection options, it defaults to http://localhost:9001 with no auth. I'm not certain about that.

It sounds like supervisorctl is searching for and finding another config file on your system, but that file contains a line that causes the Address family not supported by protocol error. It could also be that supervisorctl is using its default but the default causes this error on your system. It would be helpful if we could get more info. The last time this was reported we didn't find out.

_Edit: Clarified supervisorctl behavior._

Interesting. What was happening with me is that there was a supervisor.conf file in the current directory (the default one). When I run the command as supervisorctl I got the error, but when I switched to using supervisorctl -c supervisor.conf, I wouldn't get the error anymore. I should also note that this is from supervisor installed in a virtualenv.

From what I understand from your description, if a config file is found in the current directory, it should be used, and the behavior should be the same as running it explicitly with the -c switch. That's somehow not what happens on my end.

It appears that a commit in #95 introduced incorrect behavior (in particular, this commit: https://github.com/JensRantil/supervisor/commit/3385f17a9c465359be3f504c611700ff60bea0d4). It has been there since the end of 2011, and reverses the search order such that $CWD/etc/supervisord.conf will be found before $CWD/supervisord.conf.

I'll try to fix this in both the 3.1.X branch and master.

Oops, no, that commit is blameless. It just touched lines that were part of a preexisting bug, or at least a disagreement between the docs and the code.

Great! But FWIW, I definitely didn't have a $CWD/etc/supervisor.conf file. So I'm not sure if this bug explains the discrepancy I observed when using the -c switch.

Not sure if there is a better issue to report this in, but seems related:

If I have a supervisord.conf in the current directory, but it has no supervisorctl section, then it's impossible to run supervisorctl with command line parameters:

$ supervisorctl -s "http://192.168.1.1:9001" -i
Error: .ini file does not include supervisorctl section
For help, use /usr/local/bin/supervisorctl -h

Running the same command in a different directory works fine.

I'd suggest either allowing explicit command line arguments to override the implicitly detected config file, or informing the user that they are ignored.

version 3.1.3

I've this same problem on centos, in my conf I've added a section [supervisord] in addition to my program conf.

$ easy_install supervisor
$ supervisord -v
3.2.1
$ supervisord -c /etc/supervisord.conf
$ supervisorctl restart program:secor -c /etc/supervisord.conf
Error: .ini file does not include supervisorctl section
For help, use /bin/supervisorctl -h

I fixed the issue by concatinating echo_supervisord_conf to my config file.

I usually name sub config file as supervisord.conf in project. When you execute supervisorctl in that project folder, it would consider that supervisord.conf is main config file , which cause this error too.

Hi, I used the supervisor on the Mac to write the configuration file to execute the command
supervisord - c/Users/wujunze/etc/supervisor. The conf
Then execute supervisorctl reported this error:
http://localhost:9001 refused the connection The supervisor > update Error: < class 'socket. The error >, [61] Errno Connection refused: file: / System/Library/Frameworks/Python framework Versions / 2.7 / lib/python2.7 / socket. Py line: 575

I also have the same problem

sudo supervisorctl -c /etc/supervisor/supervisord.conf
error: <class 'socket.error'>, [Errno 99] Cannot assign requested address: file: /usr/lib/python2.7/socket.py line: 575
supervisor>

me too.
Is there a solution?

sudo service supervisor start worked for me. The daemon wasn't running

for me the solve was, the daemon was no running
sudo systemctl status supervisord
sudo systemctl enable supervisord
sudo systemctl start supervisord

ready
sudo supervisorctl reread
sudo supervisorctl start process:*

I came upon this issue with a similar error, when running in a Docker container:

# supervisorctl 
error: <class 'socket.error'>, [Errno 99] Cannot assign requested address: file: /usr/lib/python2.7/socket.py line: 575

The problem in my case was not a missing supervisord.conf in current directory, and -c supervisord.conf did not help. The problem was that the supervisord.conf in the current directory was just too thin, and was missing things that supervisorctl needs. Here's what I had to add:

[unix_http_server]
file=/var/run/supervisor.sock
chmod=0700

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

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock

docker : error: , [Errno 99] Cannot assign requested address: file: /usr/lib64/python2.7/socket.py line: 571

Docker:
error: , [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 228
The command '/bin/sh -c supervisorctl update' returned a non-zero code: 2

创建默认配置就好了

The key here is https://github.com/Supervisor/supervisor/issues/376#issuecomment-404385767. If you're setting up the supervisord config file by hand and don't include the server components, you can't connect to it via supervisorctl.

I have
I have encountered the same problem, but the usage scenario is that the virtual environment of anaconda, after the non-root user starts, the subsequent reload fails through the non-root user.

The error is as follows:
error: , [Errno 2] No such file or directory: file: /usr/work/tool/anaconda3/envs/python27/lib/python2.7/socket.py line: 228

Does the supervisor require privileged user startup?

I came upon this issue with a similar error, when running in a Docker container:

# supervisorctl 
error: <class 'socket.error'>, [Errno 99] Cannot assign requested address: file: /usr/lib/python2.7/socket.py line: 575

The problem in my case was not a missing supervisord.conf in current directory, and -c supervisord.conf did not help. The problem was that the supervisord.conf in the current directory was just too thin, and was missing things that supervisorctl needs. Here's what I had to add:

[unix_http_server]
file=/var/run/supervisor.sock
chmod=0700

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

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock

mark~

I've tried the suggestions above, and I'm getting unix:///var/run/supervisor.sock no such file when configuring the supervisord.conf file as suggested. I'm inside a Docker container running Ubuntu 20.04

Facing the python file not found an error, code=exited, status=2 once I try with the official document but still same.
I have tried so many solutions for my laravel application.

But at last, I have tried with my solution.

Here is an example for the code :

[program:dev-worker]
process_name=%(program_name)s_%(process_num)02d
command=cd /var/www/html/example.com && php artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
user=ubuntu
numprocs=8
redirect_stderr=true
stdout_logfile=/var/www/html/example.com/storage/logs/laravel.log
stopwaitsecs=3600

Ref: https://laravel.com/docs/7.x/queues#supervisor-configuration

https://stackoverflow.com/questions/41286526/supervisor-no-such-file-socket-py/65791261#65791261

The suggestion from @javabrett unfortunately causes errors like the following to be logged at each startup:

CRIT Server 'unix_http_server' running without any HTTP authentication checking

As discussed in ticket #717, this can be avoided by securing the configuration. For example:

[unix_http_server]
file=/var/run/supervisor.sock
chmod=0700
username = dummy
password = impossibleToGuess

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

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock
username = dummy
password = impossibleToGuess