Repository navigation
Periodically update timestamp of socket file so socket won't be deleted when sweeping temporary files #1710
Description
Many systems periodically sweep temporary files, deleting any that have not been accessed in a long time. Socket file timestamps are not updated when data is passed through them, so even if they are actively in use, they will appear stale to the sweeper unless they have been explicitly "touched".
This has caused a problem for the product that I work on, and it was very hard to debug. We ended up with multiple instances of supervisord after shutting down and restarting our application and couldn't figure out why that happened.
It is obviously possible for me to solve this by adding a process managed by Supervisor that periodically touches the socket file, but it would be nice if supervisord would just do that automatically. I see that PostgreSQL's socket file timestamp gets updated once every half an hour, so that seems like a good interval size.
Activity
stevecj commentedon Feb 24, 2026
Additionally (belt and suspenders) maybe check that the socket still exists at its supposed path and drop/recreate the socket if that has happened.
mnaberez commentedon Feb 24, 2026
The manual has a specific warning not to use
/tmpfor the socket file:supervisor/docs/configuration.rst
Lines 88 to 95 in abc6046
Could this warning be improved?
stevecj commentedon Feb 25, 2026
Thanks for pointing that out. I had not seen that in the manual.
The reason this came up for me is that we were having a problem keeping sockets in the application's data directory because some customers want to install that in a path that is too long for a socket file path. I moved that to the temporary directory because that path is always short, and I was following the example of PostgreSQL which keeps its socket under /tmp/ without a problem since it periodically updates the socket file's timestamp.
Earlier today, I learned from a coworker that a more standard place to put those is within /run/ .
The main improvement your warning needs is for users like me to read it. 😁 That said, it might be good to mention that /run/user/<uid>/ might be a good place to put the socket file.