Long term reliability, supervisor.sock no such file

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 https://github.com/Supervisor/supervisor/issues/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