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.
