You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Subscribing with a forced receive buffer failed. Forcing the
859
+
// buffer past net.core.rmem_max requires CAP_NET_ADMIN and a size
860
+
// the kernel accepts, so the most likely cause is a permanent
861
+
// misconfiguration; without a fallback the controller would wedge in
862
+
// the restartWaitDuration loop in run(), retrying the same failure
863
+
// once per second forever. Fall back once to the kernel-default
864
+
// buffer so neighbor updates keep flowing (at the cost of more
865
+
// frequent ENOBUFS-driven restarts under heavy churn) and remember
866
+
// the failure so we don't re-attempt (and re-leak a socket via the
867
+
// vendored library) on every restart. The error may instead be an
868
+
// unrelated socket-setup failure (e.g. fd exhaustion); in that case
869
+
// the fallback re-hits and propagates it, so no genuine error is
870
+
// masked. On the setsockopt-failure path the library returns before
871
+
// starting the goroutine that closes ch, so ch is safe to reuse.
872
+
neighForceBufferFailed.Store(true)
873
+
log.Warn("Failed to subscribe to neighbor updates with a forced netlink receive buffer; retrying without forcing it. Neighbor updates may be dropped more often under high churn. This usually means the agent lacks CAP_NET_ADMIN or the configured size was rejected against net.core.rmem_max.",
0 commit comments