In any case, if it is a bug, fixing it is hard for compatibility reasons. The code has not been touched for a very long time.
https://github.com/rsyslog/rsyslog/blame/master/runtime/conf.c#L356 Rainer El jue, 3 nov 2022 a las 10:08, Rainer Gerhards (<rgerha...@hq.adiscon.com>) escribió: > > maybe I have not fully understood the original question. Will try > later today ;-) > > However, that part of the code that parses the selectors is actually > still the same we inherited from syslogd ~20 years ago. Of course, I > can't outrule we made some changes, but I honestly don't think so. > > Rainer > > El jue, 3 nov 2022 a las 9:23, Mariusz Kruk via rsyslog > (<rsyslog@lists.adiscon.com>) escribió: > > > > I'm not saying that behaviour is wrong but I'd interpret the wording in > > the docs as Gordon intended. > > > > https://www.rsyslog.com/doc/v8-stable/configuration/filters.html > > > > "Multiple selectors may be specified for a single action using the > > semicolon (“;’’) separator. Remember that each selector in the selector > > field is capable to overwrite the preceding ones. Using this behavior > > you can exclude some priorities from the pattern." (as a side note - > > "capable" connects with "of *ing", so should be rather used as "capable > > of overwriting" but that's not the point ;-)). I'd intepret that passage > > as "if you add multiple selectors with semilcolons, the latter ones > > overwrite the former" so I'd expect it to work as Gordon did. It might > > need rewording if it works differently. > > > > MK > > > > On 2.11.2022 20:18, Rainer Gerhards via rsyslog wrote: > > > Info is higher severity than debug, so it validly matches. > > > > > > Sent from phone, thus brief. > > > > > > David Lang via rsyslog <rsyslog@lists.adiscon.com> schrieb am Mi., 2. Nov. > > > 2022, 20:10: > > > > > >> not that I expect this to fix it (this isn't something I've seen as a > > >> known > > >> bug), but could you please confirm that this still happens on the current > > >> version of rsyslog? > > >> > > >> David Lang > > >> > > >> On Wed, 2 Nov 2022, Gordon Marler (BLOOMBERG/ 120 PARK) via rsyslog > > >> wrote: > > >> > > >>> Date: Wed, 2 Nov 2022 19:01:22 -0000 > > >>> From: "Gordon Marler (BLOOMBERG/ 120 PARK) via rsyslog" > > >>> <rsyslog@lists.adiscon.com> > > >>> Reply-To: Gordon Marler <gmar...@bloomberg.net>, > > >>> rsyslog-users <rsyslog@lists.adiscon.com> > > >>> To: rsyslog@lists.adiscon.com > > >>> Cc: "Gordon Marler (BLOOMBERG/ 120 PARK)" <gmar...@bloomberg.net> > > >>> Subject: Re: [rsyslog] Reducing selector effect in RainerScript > > >>> > > >>> I've stripped down my config to just this rule, and tried with and > > >> without the stop directive - after restarting rsyslogd, of course - no > > >> change. > > >>> Also happens on the rsyslogd versions delivered with Solaris 11.4, RHEL > > >> 7.x and RHEL 8.x, which all hover around the 8.210x version > > >>> From: rsyslog@lists.adiscon.com At: 11/02/22 03:45:01 UTC-4:00To: > > >> rsyslog@lists.adiscon.com > > >>> Cc: k...@epsilon.eu.org > > >>> Subject: Re: [rsyslog] Reducing selector effect in RainerScript > > >>> > > >>> Generally, your config should work the way you indended. It's hard to > > >>> say however if other entries in your config don't cause any side > > >>> effects. > > >>> > > >>> You could add a "stop" directive to make sure that events matching your > > >>> selector won't be processed further. Like: > > >>> > > >>> *.debug;local6.err { > > >>> action( type="omfile" file="/what/ever/file") > > >>> stop > > >>> } > > >>> > > >>> On 2.11.2022 01:26, Gordon Marler (BLOOMBERG/ 120 PARK) via rsyslog > > >> wrote: > > >>>> I'm porting some configurations from syslog to rsyslog, and seeing some > > >>> unexpected selector behavior in rsyslog 8.2104 > > >>>> After reading the selector examples from the configuration portion of > > >> the > > >>> rsyslog manual, I'm either misunderstanding how this is supposed to > > >> work, or > > >>> there's a long standing issue here. > > >>>> So, the original selector looks like this: > > >>>> > > >>>> *.debug;local6.err > > >>>> > > >>>> The intent is to log all facilities at debug or higher, except for > > >> local6, > > >>> which should only log at err or higher. So I end up with a RainerScript > > >> block > > >>> like so: > > >>>> *.debug;local6.err { > > >>>> action( type="omfile" file="/what/ever/file") > > >>>> } > > >>>> > > >>>> But, I start to see messages at local6.info show up in the file, > > >> surprisingly. > > >>>> To get the desired end effect, I end up having to craft the selector > > >> like so > > >>> (which only works because only local6.info is chatty, nothing higher > > >> than > > >>> that), which surprises me: > > >>>> *.debug;local6.err;local6.!=info > > >>>> > > >>>> So, am I simply doing this wrong/misunderstanding how selectors work, > > >> or is > > >>> there something odd going on? > > >>>> > > >>>> _______________________________________________ > > >>>> rsyslog mailing list > > >>>> https://lists.adiscon.net/mailman/listinfo/rsyslog > > >>>> http://www.rsyslog.com/professional-services/ > > >>>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > >>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a > > >> myriad of > > >>> sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > >> DON'T LIKE > > >>> THAT. > > >>> _______________________________________________ > > >>> rsyslog mailing list > > >>> https://lists.adiscon.net/mailman/listinfo/rsyslog > > >>> http://www.rsyslog.com/professional-services/ > > >>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > > >> of > > >>> sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > >> DON'T LIKE > > >>> THAT. > > >>> > > >>> > > >>> _______________________________________________ > > >>> rsyslog mailing list > > >>> https://lists.adiscon.net/mailman/listinfo/rsyslog > > >>> http://www.rsyslog.com/professional-services/ > > >>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > > >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > >> DON'T LIKE THAT. > > >> _______________________________________________ > > >> rsyslog mailing list > > >> https://lists.adiscon.net/mailman/listinfo/rsyslog > > >> http://www.rsyslog.com/professional-services/ > > >> What's up with rsyslog? Follow https://twitter.com/rgerhards > > >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > > >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > >> DON'T LIKE THAT. > > >> > > > _______________________________________________ > > > rsyslog mailing list > > > https://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com/professional-services/ > > > What's up with rsyslog? Follow https://twitter.com/rgerhards > > > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > > > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > > DON'T LIKE THAT. > > _______________________________________________ > > rsyslog mailing list > > https://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com/professional-services/ > > What's up with rsyslog? Follow https://twitter.com/rgerhards > > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > > LIKE THAT. _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
