I have supervisor setup to manage a few processes. It works perfectly fine when I boot my server, however when I stop it and try to start it again it fails and give's me this error msg:

 * Starting Supervisor daemon manager...
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.
For help, use /usr/bin/supervisord -h

I'm running nginx on port 80 and 4 web servers on ports 8000, 8001, 8002, 8003

Does anyone have any idea of what is going on?

When I reboot everything works fine.


Just ran into this as well. I fixed it by doing either of these:

sudo unlink /tmp/supervisor.sock

sudo unlink /var/run/supervisor.sock

This .sock file is defined in /etc/supervisord.conf [unix_http_server] file config value (default is /tmp/supervisor.sock or /var/run/supervisor.sock).

Hope this helps someone in the future.

  • 12
    @sdolan Wow it helped me! I removed /var/run/supervisor.sock and got rid of error on Debian Stable – Abhishek A Aug 4 '10 at 14:08
  • 2
    run a find / -name supervisor.sock before you run unlink - on debian systems it sits in /var/run/, but your unlink solution worked for me – AndrewPK Jun 13 '11 at 21:55
  • 2
    Why doesn't supervisor terminate with an error code to allow scripts to unlink automatically and retry? – Tal Weiss Dec 16 '13 at 9:58
  • Be careful here. After unlinking, run "ps -ef | grep supervisord" and you'll see that the old process is still running. You may want to "kill <process_id>" as well. EDIT: This was my case while using Ubuntu 14.04. – jball037 Feb 18 '16 at 22:41
  • 1
    After the unlink command I am trying to restart supervisor but now the .sock is missed. unix:///tmp/supervisor.sock no such file. So what else do I need to do. – Robert Apr 19 '17 at 12:22

I'd use lsof to find out what process is listening on those ports.

lsof -i tcp | grep LISTEN

Once you've worked out what process it is, that's half the battle.


This would generally not be the case with you but I was hitting this error when I was mistakingly using supervisord instead of supervisorctl.