A fix would be passing SO_REUSEADDR to the setsockopt() call, so that it doesn't have to be explicitly released. Linux doesn't allow more than one listening process to bind() to a socket file anyways, so it should be perfectly safe.
One windows, this is the default behavior, and SO_REUSEADDR does something different; I don't think any problems would be caused by this change though.
EDIT: ignore this, the damned socket API is rather poorly documented; AF_UNIX sockets don't even have SO_REUSEADDR. The only way to re-use a socket is to delete the file; so it actually does need the full write permission into /var/run/.
A fix would be passing
SO_REUSEADDR
to thesetsockopt()
call, so that it doesn't have to be explicitly released. Linux doesn't allow more than one listening process tobind()
to a socket file anyways, so it should be perfectly safe.One windows, this is the default behavior, and
SO_REUSEADDR
does something different; I don't think any problems would be caused by this change though.EDIT: ignore this, the damned socket API is rather poorly documented;
AF_UNIX
sockets don't even haveSO_REUSEADDR
. The only way to re-use a socket is to delete the file; so it actually does need the full write permission into/var/run/
.