No problem, and thank you for the patch. I'll try it out and let you know how it works.
This is a huge help to me, BTW: I should be able to get my log server working properly, now, without having to worry about omruleset and multiple rulesets. (Hence my other problem report from last night.) Big sigh of relief. Not that I don't like omruleset. Like RELP, it feels really elegant, and it's easy to expressive complex log routing arrangements. I think it's one of your best ideas, to date, and I'm looking forward to trying out some crazy ideas with it. -Ryan On 2010-02-06, Rainer Gerhards <[email protected]> wrote: > Indeed, it was a bug. Patch here: > > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=85a0ed1ccefc9bf0d054dac0 > d5305b1f6cc0fe22 > > Thanks for reporting the issue! > > Rainer > >> -----Original Message----- >> From: [email protected] [mailto:rsyslog- >> [email protected]] On Behalf Of Rainer Gerhards >> Sent: Saturday, February 06, 2010 12:01 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] Why does imuxsock report its 'inputname' >> propertyas'imudp'? >> >> I will check, but the most probably explanation is that it is a bug >> that so >> far nobody noticed ;) >> >> Rainer >> >> > -----Original Message----- >> > From: [email protected] [mailto:rsyslog- >> > [email protected]] On Behalf Of Ryan Lynch >> > Sent: Friday, February 05, 2010 11:07 PM >> > To: rsyslog-users >> > Subject: [rsyslog] Why does imuxsock report its 'inputname' property >> > as'imudp'? >> > >> > Under 5.3.6, I am trying to use property-based filtering to separate >> > local messages (coming in via imuxsock, presumably) from remote >> > messages (coming in via UDP). Initially, I tried using the >> 'inputname' >> > property to distinguish between the two: >> > >> > :inputname, isequal, "imudp" /remote_udp.log >> > :inputname, isequal, "imuxsock" /local_socket.log >> > >> > With this config, nothing ever ends up in the 2nd file >> > (/local_socket.log)--instead, because the 'inputname' property is >> > always set to 'imudp', regardless of where the input originates. >> > >> > The property replacer docs mention that the value of 'inputname' >> isn't >> > guaranteed, so I guess this isn't necessarily a bug. Also, I found a >> > comment in the source code for 'imuxsock.c' that makes this behavior >> > seem to be intentional. >> > >> > Why does only imuxsock behave like this? The other input modules I've >> > used (imrelp, imklog) provide the expected 'inputname' values >> > ('imrelp' and 'imklog', respectively), which is intuitive and >> > consistent. Is there a reason why imuxsock needs to be different, or >> > is this a bug? >> > >> > (In case anyone is wondering, I could work around this by comparing >> > the 'hostname' and '$myhostname' properties, in addition to checking >> > 'inputname'. But that would force me to use expression-based filters >> > (property-based filtering doesn't support AND/OR logic), which seems >> > to increase the CPU activity per message. I really can't afford the >> > lost efficiency, here, if it can be helped.) >> > >> > Ryan B. Lynch >> > [email protected] >> > _______________________________________________ >> > rsyslog mailing list >> > http://lists.adiscon.net/mailman/listinfo/rsyslog >> > http://www.rsyslog.com >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > -- Ryan B. Lynch [email protected] _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
