Re: so_rerror

[christos%astron.com@localhost (Christos Zoulas)]

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?

christos