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