If was able to use an empty ruleset, a warning resulting from that wouldn't bother me at all.
Brian On Tue, Nov 11, 2014 at 4:25 PM, David Lang <da...@lang.hm> wrote: > On Tue, 11 Nov 2014, Rainer Gerhards wrote: > > 2014-11-11 17:22 GMT+01:00 David Lang <da...@lang.hm>: >> >> On Tue, 11 Nov 2014, Brian Knox wrote: >>> >>> Rainer, >>> >>>> >>>> I agree that an empty ruleset is an oddity. In our case, the short >>>> answer >>>> is that we are generating configurations from templates using chef, and >>>> the >>>> ability to have a ruleset that simply discards would make part of that >>>> process much simpler for us. >>>> >>>> It is admittedly an edge case. >>>> >>>> >>> It's an edge case, but I think it's one that should be supported if >>> possible. >>> >>> automated config generation is very useful, and being able to group rules >>> into rulesets and call them with the calling function not having any idea >>> of what is going to happen with the logs at that point is very useful, >>> being able to have a high level config split the logs up and call >>> different >>> rulesets on different logs without having to worry if the ruleset does >>> something with the logs or just throws them away is _very_ useful. >>> >>> So it is a corner case, but I think it's a valuable one to support. >>> >>> >>> ack >> >> >> I would suggest that at config load time, that this is an odd enough >>> corner case that it's worth logging a "ruleset X can't do anything with >>> the >>> logs" message, not just for the case where the only action is to throw it >>> away, but also for the cases where the conditions in a ruleset cannot >>> possibly match any log message (if priority = info then *.crit also >>> cannot >>> match anything for example) >>> >>> >>> Let's start with what we have on the table. I think it is best to add a >> ruleset parameter "permitEmpty=on". That way, we don't generate >> error/warning messages when the user is aware of what he is doing. In any >> manual case (without config gen), I'd still say that's an error >> indication. >> > > I think that this is a sufficently corner case that I'm not sure it's > worth the extra complexity to silence the warning. I think that people who > do this intentionally can just ignore the log message. > > On the topic of no filter matches. That's quite complex, as you would need >> to evaluate all the filters and possible conditions. Not sure if it can >> even reliably done. Am I overlooking something? >> > > I am not saying that it should try to catch every possible case, but I was > thinking that the configuration optimization step would "optomize away" > some impossible combinations, and that could result in an empty ruleset. > > David Lang > > _______________________________________________ > rsyslog mailing list > http://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 http://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.
