"why it needs to be interested i..."Ntpd needs to know the local address being used when sending to peers (authentication, which socket to use). That is why it not just reacts to
address information but also redetermines to local addresses (and sockets) are being used for reaching its peers.
The interaction with the routing socket is purposely simple. ntpd just needs to know that *something* has changed. It will then rescan after a grace period the interfaces and reevaluate
the interface/local address/socket setup. It does not need to be extremely snappy but it needs to happen.
Dropping that might delay ntpd's detection of changed local addresses for peers.
As for the message: IMHO it does not need to be logged at all (DPRINTF/maybe LOGDEBUG at most) because the overflow should and does just trigger ntpd to reevaluate the interface/routing configuration.
This information is not important at all for normal operation as the effects are correctly mitigated.
BTW: does the current code revert to (fail safe) periodic interface scanning if the routing socket is being disabled (happens when an unexpected error code is returned from read(2))?
Frank On 01/30/21 21:41, Roy Marples wrote:
On 30/01/2021 18:27, Paul Goyette wrote:On Sat, 30 Jan 2021, Roy Marples wrote:On 30/01/2021 15:12, Paul Goyette wrote:I thought we took care of the buffer-space issue a long time ago, but today I've gotten about a dozen of these: ... Jan 30 05:20:11 speedy ntpd[3146]: routing socket reports: No buffer space availableI recently adding a patch to enable the diagnostic AND take action on it. We can change the upstream default from LOG_ERR to LOG_DEBUG or maybe their custom DPRINTF though if you think that would help reduce the noise.Not concerned about noise, just wanted to make sure we didn't have a regression slip by. As long as the message is deliberate, I'm not too worried.Just to be clear on this, we have the framework to filter out routing messages we don't need to stop overflow from happening and we can also detect when overflow still happens. Currently ntpd now does both, before it just filtered out, but I didn't change what it was interested in and now I'm curious why it needs to be interested in actual routing changes for interface/address discovery as I'm pretty sure we can drop that.As we enable this in more applications we just have to make some choices - filter more out vs increasing buffer size vs just discarding the error if the prior two are not feasible.Roy