Long term reliability, supervisor.sock no such file #1723

After running supervisord for months then trying to get status it fails to get status.
Happens like every few months.

sudo supervisorctl status
unix:///tmp/supervisor.sock no such file

user@debian:/$ uptime
 12:14:26 up 259 days, 13:09,  3 users,  load average: 0.09, 0.07, 0.03

user@debian:/$  sudo service supervisord restart
user@debian:/$ sudo supervisorctl status
xxx     RUNNING   pid 340636, uptime 0:02:44
....

Tasks still run in the background, only the status fails
Daemon restart fixes the issues. (but that also means it restarts tasks, which is not healthy)
I have plenty of space/free RAM

Other than this it works great for years now.

Maybe system clean up deletes unix:///tmp/supervisor.sock ?

this is what the default config suggests

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

Shouldn't a permanent file be stored not in /tmp?

if I try to override to custom one:

[supervisorctl]
serverurl=/stuff/supervisor.sock
sudo supervisorctl status
error: <class 'ValueError'>, Unknown protocol for serverurl /stuff/supervisor.sock: file: /usr/local/lib/python3.13/dist-packages/supervisor/xmlrpc.py line: 505

They are plenty of people complaining about this
#480

Why does it work after restarting the deamon?
Seems like something changes during long term run time.
And it's not only for me. Thus seems like a supervisord bug. (it loses unix:///tmp/supervisor.sock)

//why would I have to do chmod=0777 on internal files of a running program

using
supervisor in /usr/local/lib/python3.13/dist-packages (4.3.0)

Some say

Confirmed. /tmp is a dangerous place for the supervisor.sock file:

[ec2-user@ip-172-31-1-160 ~]$ sudo supervisorctl
unix:///tmp/supervisor.sock no such file

The /etc is safer

but echo_supervisord_conf contains /tmp in example