You shouldn't have to do sudo supervisord. It should've already been started. I would try connecting after doing the restart.

Same thing:

vagrant@homestead:/etc/supervisor$ sudo service supervisor restart
Restarting supervisor: supervisord.
vagrant@homestead:/etc/supervisor$ sudo supervisorctl
unix:///var/run/supervisor.sock no such file
supervisor>

Anyone knows about this?

Is supervisord running?

pgrep -fl supervisor

If it's not, you need to figure out why; maybe look at tail -f /var/log/supervisor/supervisord.log

If it is running, then probably the config is not as expected. I would try using lsof:

vagrant@vagrant-ubuntu-trusty-64:~$ sudo lsof -c supervisord | egrep 'COMMAND|sock'
COMMAND    PID USER   FD   TYPE             DEVICE SIZE/OFF   NODE NAME
superviso 2240 root    5u  unix 0xffff8800374fa300      0t0 171865 /var/run/supervisor.sock.2233

Make sure that supervisord and supervisorctl are both using the same config file. They both support a -c option to explicitly specify the config file; this may come in handy.

Hey

This file does not exist on my computer: /var/run/supervisor.sock

Here is the code you sent:

vagrant@homestead:/etc/supervisor$ pgrep -fl supervisor
vagrant@homestead:/etc/supervisor$ tail -f /var/log/supervisor/supervisord.log
2014-08-21 06:42:44,699 INFO RPC interface 'supervisor' initialized
2014-08-21 06:42:44,699 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2014-08-21 06:42:44,709 INFO daemonizing the supervisord process
2014-08-21 06:42:44,721 INFO supervisord started with pid 32042
2014-08-21 06:46:24,288 CRIT Supervisor running as root (no user in config file)
2014-08-21 06:46:24,288 WARN Included extra file "/etc/supervisor/conf.d/queue.conf" during parsing
2014-08-21 06:46:24,353 INFO RPC interface 'supervisor' initialized
2014-08-21 06:46:24,353 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2014-08-21 06:46:24,364 INFO daemonizing the supervisord process
2014-08-21 06:46:24,372 INFO supervisord started with pid 32081

vagrant@homestead:/etc/supervisor$ sudo lsof -c supervisord | egrep 'COMMAND|sock'
vagrant@homestead:/etc/supervisor$

This is /etc/supervisor/supervisord.conf

vagrant@homestead:/etc/supervisor$ cat 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)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor ; ('AUTO' child log dir, default $TEMP)

; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket

; The [include] section can just contain the "files" setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files cannot
; include files themselves.

[include]
files = /etc/supervisor/conf.d/*.conf
vagrant@homestead:/etc/supervisor$

Same problem here, don't know how to solve it yet. :(

Same problem here

This should solve this problem:

sudo touch /var/run/supervisor.sock
sudo chmod 777 /var/run/supervisor.sock
sudo service supervisor restart

Make sure you have a [unix_http_server] and [rpcinterface:supervisor] section in your conf file

@rodrigobendia it doesn't work.

@rodrigobendia I'm having mixed results with those commands as well. As far as I can see, they work. I'm just working inside a Docker container and something keeps killing the /var/run/supervisor.sock file :) I'll try and remember to update here if/when I figure it out.

@rodrigobendia works for me. Thanks!

I found the fix. Please try.

please add below 2 section to your supervisord.conf -

[unix_http_server]
file = /var/tmp/supervisor.sock ;

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

Thanks
Vikas

@rex did you figure out why the the sock file was being killed inside the docker container?

@codingwithoutcomments I didn't, unfortunately. I was working on it for a contract gig at the time that has since ended and I no longer have access to the machine in question. :-/

may be you conf file raise this error. you should check you conf

I have had the same problem both on my Ubuntu 14.04 Lts and CentOS 7.0.1 server. It runs well untill last week.

After viewing the issues and checking the command outputting on my server. It should be caused by the permissions of directory.

The configure I used before the outputting of command echo_supervisord_conf,which indicate the file in [unix_http_server] and serverurl in [supervisorctl] section to /tmp/supervisor.sock. permission is 0770.

And I got

unix:///tmp/supervisor.sock no such file

Now I configure it to /var/run/supervisor.sock. And it works now again.

Hope this will be helpful

Still getting this problem in docker with Ubuntu 14.04 and supervisord 3.0b2

This issue also seems to be a duplicate of:
#121

I'm going to open a new issue since both are closed.

I'm going to open a new issue since both are closed.

Please do not open duplicate issues.

@mnaberez I'll just post this here then:

Test system: Clean Ubuntu 14.04 install with supervisord 3.0b2 inside a docker container.

To save time:

• It's not a config file issue. The config file exists and is being read (tried implicitly and explicitly).
• The socket file does not exist when I inspect the system
• Supervisor starts up correctly (see logs below)
• Supervisor runs with default config.
• Supervisor is running. Controlling it is not possible.
• Changing sock file permissions to 770 does nothing.
• /run (or /var/run) has the correct permissions and supervisord is started by root
• This is reproducible in multiple images

Previous issues:
#480
#121

supervisor.log:

2016-03-30 00:55:52,592 CRIT Supervisor running as root (no user in config file)
2016-03-30 00:55:52,603 INFO supervisord started with pid 6
2016-03-30 00:55:53,605 INFO spawned: 'nginx' with pid 9
2016-03-30 00:55:53,606 INFO spawned: 'php-fpm' with pid 10
2016-03-30 00:55:53,609 INFO spawned: 'newrelic-sysmond' with pid 11
2016-03-30 00:55:53,701 INFO success: newrelic-sysmond entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-03-30 00:55:54,919 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-03-30 00:55:54,919 INFO success: php-fpm entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-03-30 00:55:54,919 INFO exited: newrelic-sysmond (exit status 0; expected)

conf.d/supervisord.conf:

[supervisord]
nodaemon=true
logfile=/var/log/supervisor/supervisord.log
pidfile=/var/run/supervisord.pid
childlogdir=/var/log/supervisor

[program:nginx]
command=/usr/sbin/nginx -g "daemon off;"
user = root
autostart=true
autorestart=true
priority=10
stdout_events_enabled=true
stderr_events_enabled=true

[program:php-fpm]
command=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf
user = root
autostart = true
autorestart = true

[program:newrelic-sysmond]
command=service newrelic-sysmond start
user = root
autostart = true
startsecs=0

The configuration file above is missing a [unix_http_server] section, a [supervisorctl] section, and an [rpcinterface:supervisor] section. supervisord is not creating a socket file because it has not been configured to do so in the configuration file. See the configuration guide and the output of echo_supervisord_conf for examples of these sections.

@mnaberez Sorry I wasn't clearer. The supervisord config file at /etc/supervisor/supervisord.conf is the default one. That's just the one in conf.d (it has the same name cause that's the only way I could get supervisor to see it).

; 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)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor            ; ('AUTO' child log dir, default $TEMP)

; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL  for a unix socket

; The [include] section can just contain the "files" setting.  This
; setting can list multiple files (separated by whitespace or
; newlines).  It can also contain wildcards.  The filenames are
; interpreted as relative to this file.  Included files *cannot*
; include files themselves.

[include]
files = /etc/supervisor/conf.d/*.conf

If this configuration was being used, your log file should contain these lines:

INFO RPC interface 'supervisor' initialized
CRIT Server 'unix_http_server' running without any HTTP authentication checking

The first line is logged when [rpcinterface:supervisor] is read. The second line is logged when a [unix_http_server] section is specified without a username/password.

Since these lines are absent from your log, it does appear that supervisord hasn't been configured correctly. I would check the configuration again, e.g. perhaps supervisord is not using the configuration file(s) you think it is.

@mnaberez You're right. That was the problem. I had accidentally explicitly specified the config file as the one in conf.d, which apparently leads to the above also. facepalm Thanks so much for your help!

yes itis!

@rodrigobendia it works for me.. thanks

Why is this being closed with work arounds but no real fix? Does not work here as well (Debian 8).

Why is this being closed with work arounds but no real fix?

There's no single fix because there are many reasons why the file might not be found, and we can't control most of them: supervisord might not be running and thus didn't create it, supervisord might be running but the file may have been deleted by something else, there may be a misconfiguration, or it may even be a problem in distribution packaging. We've troubleshot this problem on the mailing list and several issues, but in all the cases I'm aware of, it ended up being one of those issues. We certainly try to fix bugs we are aware of, but at this time we don't know a bug related to this that we can fix.

Here's my problem, and how I solved it:

In one of the configuration files, there was a script that couldn't be found.

So:

1. restarting supervisor service didn't help,
2. sudo supervisord didn't help either.

First I fixed the error in the config file and sudo service supervisor restart and voila! ✌

Is supervisord running?

pgrep -fl supervisor

If it's not, you need to figure out why; maybe look at tail -f /var/log/supervisor/supervisord.log

If it is running, then probably the config is not as expected. I would try using lsof:

vagrant@vagrant-ubuntu-trusty-64:~$ sudo lsof -c supervisord | egrep 'COMMAND|sock'
COMMAND    PID USER   FD   TYPE             DEVICE SIZE/OFF   NODE NAME
superviso 2240 root    5u  unix 0xffff8800374fa300      0t0 171865 /var/run/supervisor.sock.2233

Make sure that supervisord and supervisorctl are both using the same config file. They both support a -c option to explicitly specify the config file; this may come in handy.

I am running a CentOS 7 server. For some reason, after installing Supervisor, I was unable to get it started and unable to locate the "missing" supervisor.sock file.

I installed supervisor using the following command:
sudo yum -y install supervisor

The following steps fixed it for me on CentOS 7.

1. Created the config file I want supervisor to use.
   echo_supervisord_conf > /etc/supervisord.conf

2. Updated the following line in the config file using nano (my preferred editor).
   nano /etc/supervisord.conf

[unix_http_server]
file=/var/run/supervisor/supervisor.sock   ; (the path to the socket file)

3. Made sure the supervisor directory is available in /var/run.
   mkdir -p /var/run/supervisor

4. Told supervisor where to look for the config file.
   supervisord -c /etc/supervisord.conf

5. Re-read and restarted supervisor
   supervisorctl reread && supervisorctl restart all

In my situation, this is worked for me:
mkdir /var/log/supervisor
sudo supervisord -c /etc/supervisor/supervisord.conf

I had the same problem and after I ran supervisord the log showed that the problem was coming from an old service that supervisor was trying to start but I deleted that program folder time ago, but not from the supervisor conf.d/ folder. so it was trying to start a program who didn't exist, and this caused the problem.

I had the same problem and after I ran supervisord the log showed that the problem was coming from an old service that supervisor was trying to start but I deleted that program folder time ago, but not from the supervisor conf.d/ folder. so it was trying to start a program who didn't exist, and this caused the problem.

Have you tried to re-install supervisor?

After trying every other suggestion on this page, removing and reinstalling is what finally worked for me. I wonder if there was briefly a bad package out there and that's what I had?

Remove config files
Create new config file
Restart supervisor service

You may have another supervisord.conf file somewhere in your file system. For me I found one at etc/supervisord.conf that was pointing to an old supervisor.sock file that no longer exists. Removing the old supervisord.conf fixed the problem as supervisor started to use the config I intended it to use in etc/supervisor/ folder

If I set error user in [program] such as user=notexituser,
the cmd supervisorctl restart supervisorctl status will echo

unix:///var/run/supervisor.sock no such file
or 
unix:///var/run/supervisor.sock refused connection

This is the problem I encountered.

After a big pain, by following exactly what they say here works

First remove your previous supervisor installation

sudo apt-get remove supervisor

sudo apt-get remove --auto-remove supervisor

sudo apt-get purge supervisor

sudo apt-get purge --auto-remove supervisor

Then do:

https://ekn.me/2019-11-05/how-to-use-laravel-queue-worker-with-supervisor

I suspect the issue was on the conf file name, seems that needs to be the same as the name of your program?? mmm

I know this is an ancient issue, but I figured I would comment on it because the rest of the comments don't cover the root cause of it.

Starting supervisord does indeed create the supervisor.sock file. But if the supervisor.sock file is placed in /var/tmp or /tmp, the socket will actually be periodically deleted every 30 days by either systemd-tempfiles or tmpwatch (causing all supervisor commands to fail, even though supervisord is still running). The solution is to change your supervisor config so that the socket file is put somewhere else, such as in /var/run.

Not all heroes wear capes.

For me I had this issue with no error output in the log file on supervisord version 3.3.1.

It turned out that I had a conf.d/ config with a stdout_logfile pointing to a directory that did not yet exists. Ensuring the stdout_logfile directory path exists fixed the issue for me.

#1409 (comment):

I know this is an old issue. #480
But it shows up again.
I am on Kali Linux 2020.4 VirtualBox image from:
https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-image-download/#1572305786534-030ce714-cc3b

After a clean installation with apt install supervisor
I get: unix:///var/run/supervisor.sock no such file
To solve this I run this old trick:

sudo touch /var/run/supervisor.sock
sudo chmod 777 /var/run/supervisor.sock
sudo service supervisor restart

But once I reboot the system the supervisor.sock files disappears.
And I have to use touch and chmod again.

I tried changing the location of file= and serverurl= in supervisord.conf, to different locations.
But the file always disappears no matter where I save it to.

Remove config files
Create new config file
Restart supervisor service

Solved my problem

For me I had this issue with no error output in the log file on supervisord version 3.3.1.

It turned out that I had a conf.d/ config with a stdout_logfile pointing to a directory that did not yet exists. Ensuring the stdout_logfile directory path exists fixed the issue for me.

Same here, I was using %(program_name) inside stdout_logfile and supervisor refuse to start (and no erros on /var/log/supervisor/supervisord.log file):

stdout_logfile=/var/log/supervisor/%(program_name).log

Updated with a fixed log name solved the problem. Maybe other config variables do not accept dynamic values.

stdout_logfile=/var/log/supervisor/%(program_name).log

The syntax is %(program_name)s not %(program_name) as shown above (the expansions use the Python string interpolation syntax). Please see the example config file.

Since this issue thread is still pretty active, I'll just add my case and hope it helps someone.

At first I was trying to use supervisorctl but it wouldn't work.

My supervisord.conf has the following:

[supervisord]
nodaemon=true

I didn't realize that this was for docker. See article

The important part here is the nodaemon=true, which instructs supervisor to start in the foreground instead of as a service. This lets Docker to manage its lifecycle.

So to restart the services in supservisord.conf, I just had to docker-compose stop service-name and docker-compose start service-name.

I found the fix. Please try.

please add below 2 section to your supervisord.conf -

[unix_http_server]
file = /var/tmp/supervisor.sock ;

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

Thanks
Vikas

This worked for me tnx!

What helped me solve it was that one of the programs in /etc/supervisor/conf.d/myapp.conf was poorly configured and I wasn't getting any output.
How I figured it out was:

service supervisor status

...which revealed how it tries to start. So I just paste that in manually:

/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf

This time it did tell me what the error was. It was a permission problem with one of the conf'ed apps.
Now, when fixed:

service supervisor start

worked.

The error message unix:///var/run/supervisor.sock no such file was not helpful.

After a while I found out that in one of my config files stdout_logfile and stderr_logfile were pointing to a directory that didn't exist.

I created the directory.

Supervisor started working.

I'm quite sad about this. Maybe supervisor could check things like this and report what's actually wrong with the config?

I was able to resolve this issue by stopping and starting supervisor.

sudo service supervisor stop
sudo service supervisor start

Environment : ubuntu 20.04 in docker container

I have same issue, but it resolve by below code in supervisord.conf :

# init unix http server, then supervisorctl can interactive with supervisord
[unix_http_server]
file=/var/run/supervisor.sock
chmod=0700

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

# spectify unix http server file path
[supervisorctl]
serverurl=unix:///var/run/supervisor.sock

provide help to those in need.

So I lost like a day on this problem and finally solved it :))
When i tried to sudo supervisorctl reread it showed me:
ERROR: CANT_REREAD: The directory named as part of the path /var/log/project/django .log does not exist in section 'program:project' (file: '/etc/supervisor/conf.d/project.conf')
So I went to var/log and saw that I dont even have 'project' folder, so when I did mkdir project and then sudo service supervisor restart, sudo supervisorctl reread, sudo supervisorctl update everything finally worked, hope it helps you! gl

Every year I fought this problem which every time forgot.
And always problem is just in random old unused config within /etc/supervisor/conf.d/
Just deleting it, ends my 2 hours of searches.

Sometimes it happens if directory where are you logging to is not exists. Check stdout_logfile and stderr_logfile paths.