12

I'm running Supervisord on my Ubuntu 14.04 server and everything works fine. I deploy using a git push and upon deployment I also need to restart my application server (gunicorn) which I can supposedly do using supervisorctl.

In my supervisord.conf, gunicorn is defined as follows:

[program:gunicorn]
command=/home/imb/imb/venv/bin/gunicorn --worker-class eventlet -b 127.0.0.1:5000 -w 1 app:app
directory=/home/imb/imb
autostart=true
autorestart=true
stdout_logfile=/tmp/gunicorn.log
redirect_stderr=true
stopsignal=QUIT

and I enabled supervisorctl like this:

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

I started supervisor using:

sudo supervisord -c /home/imb/imb/supervisord.conf

As far as I understand I now should be able to restart gunicorn using the command supervisorctl restart gunicorn, but when I do that I get

$ supervisorctl restart gunicorn
unix:///var/run/supervisor.sock no such file

I checked and the file /var/run/supervisor.sock indeed doesn't exist, even though I'm sure supervisor is in fact running:

$ ps -A | grep supervisor
27211 ?        00:00:00 supervisord

Does anybody know why the /var/run/supervisor.sock file isn't created, even though supervisor is clearly running? All tips are welcome!

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
kramer65
  • 1,394
  • 4
  • 21
  • 43
  • 2
    Have you seen this post? http://stackoverflow.com/questions/10716159/nginx-and-supervisor-setup-in-ubuntu Have you tried any of its oslutions? Do they work? If they do not, how do they fail? – MariusMatutiae May 01 '16 at 07:27

8 Answers8

12

Alright, after messing around some more I found what I did wrong.

Turns out the lines for supervisorctl below, only tell supervisorctl where it can find the socket file.

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

Further above in the file there are two other lines which define where the file is actually created:

[unix_http_server]
file=/tmp/supervisor.sock

As you can see that created the socket file in /tmp/ while supervisorctl tried to read it from /var/run/. I changed the last line to file=/var/run/supervisor.sock and now it works beatifully.

I hope this answer might help someone else dealing with the same trouble.

Also, you can check out the link provided by @MariusMatutiae in the comments: https://stackoverflow.com/questions/10716159/nginx-and-supervisor-setup-in-ubuntu

Community
  • 1
kramer65
  • 1,394
  • 4
  • 21
  • 43
  • 3
    I see that the page I suggested did contain the right solution for you, http://stackoverflow.com/a/28469044/2796243 . I am glad to see I could help, cheers. – MariusMatutiae May 05 '16 at 06:35
  • @MariusMatutiae - Yes indeed, I might not have given you the recognition which you deserved. So a big thanks to you! Note that I'm still happy to give you the 50 bounty points. Just write an answer and I'll reward it to you.. :-) – kramer65 May 05 '16 at 08:54
  • Thanks, very nice of you, but I did not **really** find the solution. It's just that the page above contains several different solutions, only one of which (happily) applies to you, but it can be helpful to others reading this post to know that other solutions may be available, should the need arise. That's all. Cheers. – MariusMatutiae May 05 '16 at 10:48
  • I faced another "funny" problem. Don't use tmp folder for socket file as it's cleaned automatically and socket file will be erased till next supervisord restart. – StalkAlex Jan 06 '17 at 09:25
6

For users who have the same entry for both 

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock

&

[unix_http_server]
file=/tmp/supervisor.sock

follow below steps to fix the problem -

  1. Delete .sock file from /tmp
  2. Run 'supervisord' command. This will recreate the sock file.
  3. Run 'supervisorctl -i' to check the status of the services.

Hope this helps you!

saurabh
  • 161
  • 1
  • 1
3

After too much struggling with this issue, with everybody telling me to just enable or restart which was not working. I finally found out the solution for me:

  • First of all acknowledge that you have the main supervisor.conf file here: /etc/supervisor/supervisor.conf
  • If you are in my case, you also have a project specific .conf file in here: /etc/supervisor/conf.d/project.conf

Somehow supervisorctl was working fine but the weird thing is that doing service supervisor restart breaks everything and you get the error of OP.

The solution then is to:

  1. Rename project.conf to project.conf.tmp
  2. Then service supervisor restart (after what supervisorctl works again)
  3. You rename back your project conf file to project.conf
  4. supervisorctl reread, supervisorctl update, supervisorctl restart all
lapin
  • 171
  • 4
0

vi /opt/conf/supervisord.conf 

[supervisord]
nodaemon=true

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

; rpc interface for supervisorctl
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

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

[program:program1]

run supervisord

/usr/bin/supervisord -c /opt/conf/supervisord.conf

run supervisorctl

/usr/bin/supervisorctl -c /opt/conf/supervisord.conf
Tinkaal Gogoi
  • 101
  • 2
0

I had the problem that supervisord was running within a docker container. When I wanted to use the supervisorctl command the only response was unix:///var/run/supervisor.sock no such file.

The solution to my problem was that I had to execute the supervisorctl command as the root.

sudo supervisorctl

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

Seb
  • 101
  • 1
0

For me the issue was missing log file mention in the supervisor.conf file

Fix:

touch /var/log/supervisor/supervisord.log
Gagan Jakhotiya
  • 1
  • 1
0

This issue occured because a directory was missing in one of the config files for one of my programs. Once I made the directory, supervisorctl started fine.

nadermx
  • 667
  • 1
  • 10
  • 32
-2

Upgrade it to MacOS Sierra 10.12.5.

I faced the same issue and everything was right in the config file as well. Later I figured that I had moved to latest MacOS Sierra 10.12.3 and then it didn't work. It had been working on the older version but not at this specific version of MacOS. Then I upgraded it to MacOS Sierra 10.12.5 and everything seems to be working fine.

Kamil Maciorowski
  • 69,815
  • 22
  • 136
  • 202
Isha
  • 1