Ok then I need to see how I can fiddle that into the grammar ;) Sent from phone, thus brief. Am 19.11.2014 19:56 schrieb "David Lang" <da...@lang.hm>:
> On Wed, 19 Nov 2014, Rainer Gerhards wrote: > > 2014-11-19 16:40 GMT+01:00 Brian Knox <bk...@digitalocean.com>: >> >> Ok - perhaps we have accidently conflated two problems: >>> >>> 1) An empty ruleset >>> 2) A ruleset with only "stop" >>> >>> this will pass validation: >>> >>> ------------------------------------ >>> ruleset(name="foo") { >>> stop >>> } >>> *.* /var/log/test >>> call foo >>> ------------------------------------ >>> >>> If the ruleset is empty, however, it will not: >>> >>> ------------------------------------ >>> ruleset(name="foo") { >>> } >>> *.* /var/log/test >>> call foo >>> ------------------------------------ >>> >>> rsyslogd: version 8.5.0, config validation run (level 1), master config >>> ./test.conf >>> rsyslogd: error during parsing file ./test.conf, on or before line 2: >>> syntax error on token '}' [try http://www.rsyslog.com/e/2207 ] >>> rsyslogd: CONFIG ERROR: could not interpret master config file >>> './test.conf'. [try http://www.rsyslog.com/e/2207 ] >>> rsyslogd: run failed with error -2207 (see rsyslog.h or try >>> http://www.rsyslog.com/e/2207 to learn what that number means) >>> >>> >>> OK, that's a different question. Is the consensus we need to support >> this >> as well? >> > > I think so, with a warning reported at startup or something like that. > > David Lang > > Rainer >> >> >> Brian >>> >>> >>> >>> On Wed, Nov 19, 2014 at 10:35 AM, Brian Knox <bk...@digitalocean.com> >>> wrote: >>> >>> For verifying the problem I ran rsyslog -N1 -f against just the subset >>>> of >>>> the config, if I recall correctly. I believe my coworker had the same >>>> issue with the full config that definitely had actions in it - but I'll >>>> >>> ask >>> >>>> him to reproduce with the full configuration. Thanks! >>>> >>>> Brian >>>> >>>> On Wed, Nov 19, 2014 at 10:13 AM, Rainer Gerhards < >>>> rgerha...@hq.adiscon.com> wrote: >>>> >>>> Brian, >>>>> >>>>> I just revisited this problem report. I have now taken a look at the >>>>> >>>> code. >>> >>>> The error message actually tells you that there is no action inside the >>>>> *entire config*, not just an empty ruleset. Can you confirm there was >>>>> nothing else in the config? If not, can you send me the config, so that >>>>> >>>> I >>> >>>> can try to see what's going on. >>>>> >>>>> I assume we agree that a totally action-less config is an error ;) >>>>> >>>>> Rainer >>>>> >>>>> 2014-11-11 22:49 GMT+01:00 Brian Knox <bk...@digitalocean.com>: >>>>> >>>>> 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. >>>>>> >>>>>> _______________________________________________ >>>>> 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. >>> >>> _______________________________________________ >> 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. > _______________________________________________ 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.