Pablo Neira Ayuso пишет:
Alexander Kolesnik wrote:
Hello Pablo,
Thanks for the answer!
/etc/ulogd.conf:
rmem=442368
PNA> ^^^^^^
PNA> Rising this value will delay hitting ENOBUFS. This is the size of the
PNA> receiver buffer.
1. "delay" means I will get ENOBUFS in any case (early or later)?
Yes, but as said, you can tune different parameters to make it harder to
happen, like rising qthreshold, reducing cprange, setting a lower nice
value for ulogd.
2. What ENOBUFS does depend on? Packets per second? Bytes per second?
Amount of iptables/shaping rules? CPU performance?
On the queue size, bytes/s sent to ulogd and on how slow ulogd is
reading messages.
3. Is there any way to calculate or predict the high limit of
traffic rate/number of rules/etc when the system will still manage to
process ULOG without alerting with ENOBUFS?
I don't know any, at least yet.
4. ipcad buffers (I suppose this is the same as rmem for ulogd) is set
to 4M:
/etc/ipcad.conf:
buffers = 4194304;
But I'm still losing ULOG messages. Does that mean I have to rise this
value more?
Rising the value to the infinite is not either a solution, you'll hit
ENOBUFS sooner or later.
I experimented with the configuration, but never succeeded. Packages are
lost after 2MBit/s. For the solution of the problem I used other package
- ulog-acctd. It's works perfect.
--
With best regards, Nikolay Ilkevich.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
