[rsyslog] rsyslog - what's next?
RB
aoz.syn at gmail.com
Mon Jul 13 23:24:10 CEST 2009
On Mon, Jul 13, 2009 at 14:38, <david at lang.hm> wrote:
> HUP does not interrupt services.
I'm sorry; last October you noted that for certain configurations
SIGHUP will drop memory-queued messages. In addition to the other
notes in the thread (tearing down TCP connections, etc.), it sounds an
awful lot like a service interruption. Has that since changed for 3.x
or 4.2?
> the system calls to access it (and to first lookup if it should be
> accessed at all) take enough time to be significant at these speeds.
May I gently prod you to substantiate this statement? I don't doubt
that it makes calls to external libraries, and that those calls are
likely more expensive than internal resolution, but "significant" is
not significant without numbers to back it up. Even a simple speed
comparison for a few million packets between 'no resolution' and 'in
/etc/hosts with a cold cache' would be useful.
> you want the ability to cache the name lookup no matter what method is
> used. only DNS provides a TTL, hosts files, NIS, LDAP, etc do not include
> a TTL.
I have no problem expanding the scope of discussion to resolution
methods beyond DNS (which was the original premise), but if a name
service does not provide an explicit TTL, it must be assumed as an
implicit '0', which blind caching will break. That said, each of
those methods still provides some [internal] method of caching and
invalidation that, to be audit-grade correct, rsyslog will either have
to replicate or trust. I still can't see a problem with having
something to the effect of a "$BreakNSCache" configuration option, but
by default a syslog daemon should play as strictly by the rules as
possible.
Then again, I'm RB, not RG. ;)
More information about the rsyslog
mailing list