tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: so_rerror



On 04/11/2018 22:54, Christos Zoulas wrote:
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...

Yes they will.
abs emailed me off list about adding a staggered error report for syslogd rather than each time which is another option, but I don't have the time for that right now. But again, it's just another mask on the problem.

Now that syslogd has the tools to make you happy, can we at least make the default value of the new sysctl (which I note is not the boolean which both Martin and Jason asked for) set to report overflow? Then I think everyone is happy.

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?

I *think* you're incorrect.
Each message sent enters a queue. If this queue overflows, we can't report anything to userland and the kernel will log a diagnostic (afaik no-one has reported this yet). For each message which enters the queue it's then processed per socket, then the filtering applies and it enters the receive buffer if it passes.

Now message queue length is a different beast from buffer sizes granted and the only way I see of optimizing it would be to test if all interested sockets have filters and any filter wants it - if so, it enters the queue, otherwise it doesn't. But as I said earlier, I don't recall any users reporting this diagnostic, I for sure have never seen it and it might be pointless optimisation implementing my suggestion.

Roy


Home | Main Index | Thread Index | Old Index