In article <d3c2a03d-357a-89d1-c4b4-bbc8ba9c26bd%marples.name@localhost>,
Roy Marples <roy%marples.name@localhost> wrote:
Whether it arrived at the kernel by UDP or carrier pigeon and could not
be delivered for reason X, we should not be discarding this silently.
However, I do buy into the argument that syslogd can't keep up with
incoming data in all situations. To facilitate this, I've added the -B
option so you can specify a large buffer.
Also, it might be that the system is just to slow to log the amount of
incoming data so I've added the -X option so ENOBUFS can be silently
discarded.
So as of right now, the admin can see overflow and they can make the
choice about how to handle it. Surely you must agree that this is a good
default rather than leaving the admin to worry if their logger actually
logged everything or not.
That fixes syslogd, thanks. Still sending is always more efficient than
receiving, and no matter how big the buffers are, you will overflow them
using a fast sender...
This is actually untrue.
All programs that care about the routing socket have already set socket
filters to avoid the messages (ie compat versions) they don't care
about. These filters run before overflow can happen.
And still dhcpcd reports overruns before we increased the size of the
buffers. It still does, but only on my router and only at boot time, but
thankfully it now has the code resync itself to the real system state.
The filters are running on the receiving side (IIRC), which means that
the kernel still needs to do all the needless work to send all versions
and it can overflow on the send side. So the filters help only on the
receive side overflow, or am I understanding this incorrectly?