Hey!
Just got an instance of BIRD dying unexpectedly after displaying the
following message:
nl_get_reply: No buffer space available
It's from netlink.c:
int x = recvmsg(nl->fd, &m, 0);
if (x < 0)
die("nl_get_reply: %m");
Manpage for netlink(7) says an application should expect such a
condition:
However, reliable transmissions from kernel to user are
impossible in any case. The kernel can't send a netlink message
if the socket buffer is full: the message will be dropped and the
kernel and the user-space process will no longer have the same
view of kernel state. It is up to the application to detect when
this happens (via the ENOBUFS error returned by recvmsg(2)) and
resynchronize.
Another possibility would be to use NETLINK_NO_ENOBUFS socket option:
This flag can be used by unicast and broadcast listeners to avoid
receiving ENOBUFS errors.
I don't think using this flag is a good idea.
I thought this problem has already been reported recently, but I didn't
find the thread back. The receive buffer could be increased dynamically
when this happens. Or maybe we could just ignore the error and wait for
the next kernel sync to catch up. Or the 8192 value could be configured
at build-time. What's the best option?
--
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)
