I installed Supervisor on a shared Debian life server. My unix_http_server configuration in the supervisord.conf looks like this:
[unix_http_server]
file=/tmp/supervisor.sock
When I run: supervisord -c supervisord.conf
I´m getting this error message two times a second:
Unlinking stale socket /tmp/supervisor.sock
The socket in the /tmp folder is created and looks like this: /tmp/supervisor.sock.832907 (the six-digit number is generated randomly)
Help would be appreciated
THX
I am sure my reply is not very helpful, but anyway....
FYI, I never create / configure unix domain sockets for applications in the /tmp directory. "Strange things" often happen in that directory 
So when I create/configure/use a socket like that I always put it in some place like /var/run for example (especially on Linux-based systems).
in addition to Neo's answer, see the warning here: Configuration File — Supervisor 4.2.5 documentation.
I've been looking for the answer to this problem too. Thanks for the info
This confirms my intuition and experience, thanks @bendingrodriguez
My advise is to never use /tmp for anything important, especially a production unix domain socket in an application.
Think of /tmp like a kind of "trash can".
Don't run your production sockets in your trash can.
I also wanted to add that having the example set up in "the trash can" was misleading for users and that application team should change the example socket configuration so busy users are not required to read the big orange warning which states, in effect, "Do not do what we just did."
In addition to files in /tmp being deleted, I have also found strange permissions on files there from time-to-time (cannot recall at this time, exactly) which also cause issues and problems.
Do not use "the trash" as a place to run your business 
one more note about /var/run: At least on newer Debian based systems you should use /run, since /var/run is just a link to it. Otherwise annoying warnings like this one arise:
systemd[1]: /lib/systemd/system/rpc-statd.service:16: PIDFile= references a path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly.
Or, what I would do if this was an issue on my systems, would be to remove the symbolic link:
lrwxrwxrwx 1 root root 4 Dec 13 2017 /var/run -> /run
and just make /var/run a directory, not a sym link to /run.
Seems "lazy" by Debian-like systems (including Ubuntu) to make this important directory a sym link, because I think /var/run is a better place than /run for these unix domain sockets; but that's only my personal opinion, not actually-based in any tech facts.
But on the other hand, I've never had a system problem on Ubuntu with the current sym link configuration.
I have already had problems with systems that use /run and /var/run as real dirs, but unfortunately I can no longer remember exactly which problems. The current FHS also recommends /run: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html.