[syslog-ng]AIX and repeated message formats - fix?

[Jon Marks]

On Wed, May 02, 2001 at 11:53:04AM +0200, Balazs Scheidler wrote:
> On Fri, Apr 27, 2001 at 04:39:32PM -0500, Jon Marks wrote:
> > Earlier I posted a message asking about whether syslog-ng had standard
> > equipment for dealing with a couple of strange message types:
> > 
> > 1) Messages forwarded by AIX syslogd which contain the string
> > 
> >    "Message forwarded from [hostname]: " ...
> > 
> > and 
> > 
> > 2) Messages of the form:
> > 
> >    "last message repeated _n times"
> > 


> 
> Are you absolutely sure there's no other way to recognize these messages
> other than parsing their contents? To be honest I don't like putting too
> much system dependency into syslog-ng.
> 
> A compile time/runtime option should be integrated though if there's no
> other way.
> 
> -- 
> Bazsi
> PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
> 
> _______________________________________________
> syslog-ng maillist  -  syslog-ng@lists.balabit.hu
> https://lists.balabit.hu/mailman/listinfo/syslog-ng

I can certainly understand that chasing system specifics is very
problematic-- I only know of the incongruities AIX introduces, but I'm
sure other syslogd implementations must do their own things, too. Also,
the "last message repeated" problem is from Solaris syslogd, and I think
from lots of others. Adding these extra tests where I've put them would
make the critical message parsing code bulky and slow.  The problem is,
in my environment, I *need* to be able to handle these.  So I suppose
the issue is one of interoperability. Syslog-ng is great because it
gives us what the old brainless syslogd couldn't-- but there's still a
lot more of the old brainless daemons out there.

I'm only familiar with the code in log.c and sources.c, since that's
where I could address the issue directly. What I figured out is that log
messages' program fields are never re-evaluated after parsing the message,
and the host field is either kept (via keep_hostname or chain_hostnames),
or replaced by the message's last hop's address.  So it seemed necessary
to get these fields right during the parsing phase. I don't think there's
any other way (or place in the code I've looked at thoroughly) to detect
these types of messages.

I didn't want to slow things down too much, but I figured memcmp wouldn't
hurt too bad. If the message doesn't match the new extra tests, unless the
hostname is "last" or "Message" then the memcmp will fail quickly. Even
if the message does match, it's only comparing a few extra bytes. It's
probably safe to shave off a few bytes from the test strings, too.

I agree that some kind of compilation or runtime switch would be a good
idea for system-dependent stuff. One of my coworkers suggested that, too.
I'm not as familiar with the configuration file lexical analysis and parsing
parts of the code, and I'm still struggling a little to understand libol
and the object-oriented framework. I'd like to have offered that in my
patch-- perhaps I could work that out in the future.

-- 
Jonathan Marks

Systems Administrator, Production Systems Group
Computing and Communication Services Office
University of Illinois at Urbana-Champaign