2014-11-19 16:40 GMT+01:00 Brian Knox <[email protected]>: > 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?
Rainer > Brian > > > > On Wed, Nov 19, 2014 at 10:35 AM, Brian Knox <[email protected]> > 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 < > > [email protected]> 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 <[email protected]>: > >> > >> > 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 <[email protected]> wrote: > >> > > >> > > On Tue, 11 Nov 2014, Rainer Gerhards wrote: > >> > > > >> > > 2014-11-11 17:22 GMT+01:00 David Lang <[email protected]>: > >> > >> > >> > >> 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.
