Setsockopt SO_REUSEADDR failed

NSD
1

Hello,

I'm running NSD 3.2.1 on Solaris 10 (sparc) and I've noticed that this
messages shows up in syslog on a regular base:

May 5 11:36:47 bender nsd[2005]: [ID 702911 daemon.warning] xfrd:
setsockopt SO_REUSEADDR failed: Invalid argument

As far NSD works as expected, I'm wondering how I should deal with this
message.

Ihsan

2

Hi Ihsan,

This means that the setsockopt function for the option SO_REUSEADDR
failed. This may be because the option is undefined in Solaris 10.
Otherwise, the setsockopt failed and returned the error E_INVAL.

What does SO_REUSEADDR do? It basically says the socket can use an
address already in use. This is useful if your server is being
restarted, while sockets may still be active on the port.

If SO_REUSEADDR failed, we try to set the SO_LINGER socket option. This
tells the socket to return immediately after a close(). For the client
it looks like if the connection was reset. For the server, we prevent
that binding the outgoing interface fails after a restart, because the
port could still be in use.

So, this isn't a fatal error. Even if we failed to set the SO_LINGER
option, we will still try to bind the interface.

Should we increase the verbosity for these log messages?

Kind regards,

Matthijs Mekking
NLnet Labs

Ihsan Dogan wrote:

3

* Matthijs Mekking:

So, this isn't a fatal error. Even if we failed to set the SO_LINGER
option, we will still try to bind the interface.

Should we increase the verbosity for these log messages?

I think the picture is far less rosy than you paint it here. I'm sure
Solaris 10 supports SO_REUSEADDR, so there's probably something amiss
if the setsockopt call fails.

4

Am 6.5.2009 21:29 Uhr, Florian Weimer schrieb:

So, this isn't a fatal error. Even if we failed to set the SO_LINGER
option, we will still try to bind the interface.

Should we increase the verbosity for these log messages?

I think the picture is far less rosy than you paint it here. I'm sure
Solaris 10 supports SO_REUSEADDR, so there's probably something amiss
if the setsockopt call fails.

Isn't this then a bug, which needs to be fixed?