Perfectly fine with a doc fix; we're converting from syslog selectors that 
predate the 2000s (probably from around 1984 or so).

So I'm still left with the question of how best to convert a selector like the 
following examples to something more modern, maintaining the old/original 
intent of:

 "capture everything at first, then whittle away priority ranges of individual 
facilities"

Example #1:

*.debug;local6.err   <file>

Which translates to:


*Start by logging all facilities, all priorities to <file>
*Eliminate local6.{debug,info,notice,warn}

Example #2:

*.debug;mail.none;local2.none;lpr,local4,local6.err  <file>

Which translates to:


*Start by logging all facilities, all priorities to <file>
*Eliminate mail.*
*Eliminate local2.*
*Eliminate {lpr,local4,local6}.{debug,info,notice,warn}


I'm going to look at using the if-then construct and see if it's an easy 
conversion; it'd just be nice to know if it's possible to still craft the old 
style selector to achieve the same end result.

From: rsyslog@lists.adiscon.com At: 11/03/22 08:47:57 UTC-4:00To:  
rsyslog@lists.adiscon.com
Cc:  k...@epsilon.eu.org
Subject: Re: [rsyslog] Reducing selector effect in RainerScript

+1 on the doc fix. It's not that it's a bug per se. And I suppose there 
might be installations "in the wild" relying on the filter specification 
mechanics so I don't think changing it is called for. It's just that the 
docs should probably more closely represent it.

MK

On 3.11.2022 13:05, Rainer Gerhards wrote:
> It's complicated. This may be a bug. I tend to say it is, although some
> may argue the man page text does not cover this specific case.
>
> Anyhow, this was not introduced into rsyslog, but into sysklogd. My
> earliest commit is from 2004, with a little bit of non-git history
> before. I can't find the original sysklogd source any longer, but I am
> totally sure we did not touch this part of the code in the early
> 2000's (we were focussed on database writing).
>
> Have a look at the original code, and head to line 2512. It's (minus
> cosmetic utility function changes) the same code as it is today.
>
> 
https://github.com/rsyslog/rsyslog/commit/05f2f1839c2712ca77e86aa679dc909d051fc2
3b?diff=unified#diff-9d04cb1c9964eae767720b1cfc19111074b0fe23e22416d8594872c4973
7a304R2512
>
> Even more so, the man page text also stems directly back to sysklogd,
> without any alteration in wording.
>
> How to go forward? Of course I can fix this "bug", but that would
> probably cause a loooot of grief with long-existing configs. So I
> would tend to say it is a doc bug so let's fix the doc and be done.
>
> Any comments? David Lang maybe?
>
> Rainer
>
> El jue, 3 nov 2022 a las 10:26, Rainer Gerhards
>
> (<rgerha...@hq.adiscon.com>) escribió:
>> 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.

_______________________________________________
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.

Reply via email to