Re: [rsyslog] ruleset with only stop
As it looks, this does the trick:
https://github.com/rsyslog/rsyslog/commit/4cc10e7434d21f98e5cacd542edb834f894db620
It's currently in master-candidate and will migrate to master when the
testruns look good (the manual one did).
Totally empty configs are still not tolerated. I'll see if I can add an
option for that.
Rainer
2014-11-19 20:07 GMT+01:00 Brian Knox bk...@digitalocean.com:
Thanks!
On Wed, Nov 19, 2014 at 1:59 PM, Rainer Gerhards rgerha...@hq.adiscon.com
wrote:
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
Re: [rsyslog] ruleset with only stop
2014-11-20 15:59 GMT+01:00 Rainer Gerhards rgerha...@hq.adiscon.com:
As it looks, this does the trick:
https://github.com/rsyslog/rsyslog/commit/4cc10e7434d21f98e5cacd542edb834f894db620
It's currently in master-candidate and will migrate to master when the
testruns look good (the manual one did).
Totally empty configs are still not tolerated. I'll see if I can add an
option for that.
I have now extended the -N option to support -N3, which can be used for
checking include files:
https://github.com/rsyslog/rsyslog/commit/a75eb98c058665d82f168f834b392683b30e001d
It does not require the existence of actions.
Rainer
Rainer
2014-11-19 20:07 GMT+01:00 Brian Knox bk...@digitalocean.com:
Thanks!
On Wed, Nov 19, 2014 at 1:59 PM, Rainer Gerhards
rgerha...@hq.adiscon.com
wrote:
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
Re: [rsyslog] ruleset with only stop
Nice! Thanks Rainer!
Brian
On Thu, Nov 20, 2014 at 12:28 PM, Rainer Gerhards rgerha...@hq.adiscon.com
wrote:
2014-11-20 15:59 GMT+01:00 Rainer Gerhards rgerha...@hq.adiscon.com:
As it looks, this does the trick:
https://github.com/rsyslog/rsyslog/commit/4cc10e7434d21f98e5cacd542edb834f894db620
It's currently in master-candidate and will migrate to master when the
testruns look good (the manual one did).
Totally empty configs are still not tolerated. I'll see if I can add an
option for that.
I have now extended the -N option to support -N3, which can be used for
checking include files:
https://github.com/rsyslog/rsyslog/commit/a75eb98c058665d82f168f834b392683b30e001d
It does not require the existence of actions.
Rainer
Rainer
2014-11-19 20:07 GMT+01:00 Brian Knox bk...@digitalocean.com:
Thanks!
On Wed, Nov 19, 2014 at 1:59 PM, Rainer Gerhards
rgerha...@hq.adiscon.com
wrote:
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_
Re: [rsyslog] ruleset with only stop
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.
Re: [rsyslog] ruleset with only stop
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
Re: [rsyslog] ruleset with only stop
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)
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.
Re: [rsyslog] ruleset with only stop
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?
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
Re: [rsyslog] ruleset with only stop
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
Re: [rsyslog] ruleset with only stop
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
Re: [rsyslog] ruleset with only stop
Thanks!
On Wed, Nov 19, 2014 at 1:59 PM, Rainer Gerhards rgerha...@hq.adiscon.com
wrote:
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
Re: [rsyslog] ruleset with only stop
2014-11-10 16:23 GMT+01:00 Brian Knox bk...@digitalocean.com:
Today I noticed a ruleset with only stop as it's action will fail to
parse with rsyslog 8.4, but the same rule with a ~ will pass.
ruleset(name=testme) {
*.* ~
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master config
./test.conf
rsyslogd: warning: ~ action is deprecated, consider using the 'stop'
statement instead [try http://www.rsyslog.com/e/2307 ]
Changing to stop :
ruleset(name=testme) {
stop
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master config
./test.conf
rsyslogd: CONFIG ERROR: there are no active actions configured. Inputs will
run, but no output whatsoever is created. [try
http://www.rsyslog.com/e/2103
]
rsyslogd: run failed with error -2103 (see rsyslog.h or try
http://www.rsyslog.com/e/2103 to learn what that number means)
I have a situation where rules are being generated via templates in chef,
and having a rule that just discards messages would actually be a useful
thing to have, and ran into this.
So my question is, should a rule that only calls a discard action be
valid? If so, is this a bug in the config parser?
It's a little bit complex. The thing is that ~ actually *is* an action,
whereas stop is a statement. When I wrote that checking code, I never
envisioned that an empty ruleset could be useful for any case (if there is
just a stop inside it, it's practically empty, in that it simply does
nothing). I think in most cases this really is a config error. Maybe I
could add an permitEmpty parameter to the ruleset, which will then not
emit that error message.
To understand the whole picture: why do you need these empty rulesets?
Rainer
Brian
___
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.
Re: [rsyslog] ruleset with only stop
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.
Brian
On Tue, Nov 11, 2014 at 4:06 AM, Rainer Gerhards rgerha...@hq.adiscon.com
wrote:
2014-11-10 16:23 GMT+01:00 Brian Knox bk...@digitalocean.com:
Today I noticed a ruleset with only stop as it's action will fail to
parse with rsyslog 8.4, but the same rule with a ~ will pass.
ruleset(name=testme) {
*.* ~
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master config
./test.conf
rsyslogd: warning: ~ action is deprecated, consider using the 'stop'
statement instead [try http://www.rsyslog.com/e/2307 ]
Changing to stop :
ruleset(name=testme) {
stop
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master config
./test.conf
rsyslogd: CONFIG ERROR: there are no active actions configured. Inputs
will
run, but no output whatsoever is created. [try
http://www.rsyslog.com/e/2103
]
rsyslogd: run failed with error -2103 (see rsyslog.h or try
http://www.rsyslog.com/e/2103 to learn what that number means)
I have a situation where rules are being generated via templates in chef,
and having a rule that just discards messages would actually be a useful
thing to have, and ran into this.
So my question is, should a rule that only calls a discard action be
valid? If so, is this a bug in the config parser?
It's a little bit complex. The thing is that ~ actually *is* an action,
whereas stop is a statement. When I wrote that checking code, I never
envisioned that an empty ruleset could be useful for any case (if there is
just a stop inside it, it's practically empty, in that it simply does
nothing). I think in most cases this really is a config error. Maybe I
could add an permitEmpty parameter to the ruleset, which will then not
emit that error message.
To understand the whole picture: why do you need these empty rulesets?
Rainer
Brian
___
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.
Re: [rsyslog] ruleset with only stop
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.
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)
David Lang
Brian
On Tue, Nov 11, 2014 at 4:06 AM, Rainer Gerhards rgerha...@hq.adiscon.com
wrote:
2014-11-10 16:23 GMT+01:00 Brian Knox bk...@digitalocean.com:
Today I noticed a ruleset with only stop as it's action will fail to
parse with rsyslog 8.4, but the same rule with a ~ will pass.
ruleset(name=testme) {
*.* ~
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master config
./test.conf
rsyslogd: warning: ~ action is deprecated, consider using the 'stop'
statement instead [try http://www.rsyslog.com/e/2307 ]
Changing to stop :
ruleset(name=testme) {
stop
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master config
./test.conf
rsyslogd: CONFIG ERROR: there are no active actions configured. Inputs
will
run, but no output whatsoever is created. [try
http://www.rsyslog.com/e/2103
]
rsyslogd: run failed with error -2103 (see rsyslog.h or try
http://www.rsyslog.com/e/2103 to learn what that number means)
I have a situation where rules are being generated via templates in chef,
and having a rule that just discards messages would actually be a useful
thing to have, and ran into this.
So my question is, should a rule that only calls a discard action be
valid? If so, is this a bug in the config parser?
It's a little bit complex. The thing is that ~ actually *is* an action,
whereas stop is a statement. When I wrote that checking code, I never
envisioned that an empty ruleset could be useful for any case (if there is
just a stop inside it, it's practically empty, in that it simply does
nothing). I think in most cases this really is a config error. Maybe I
could add an permitEmpty parameter to the ruleset, which will then not
emit that error message.
To understand the whole picture: why do you need these empty rulesets?
Rainer
Brian
___
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.
Re: [rsyslog] ruleset with only stop
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.
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?
Rainer
David Lang
Brian
On Tue, Nov 11, 2014 at 4:06 AM, Rainer Gerhards
rgerha...@hq.adiscon.com
wrote:
2014-11-10 16:23 GMT+01:00 Brian Knox bk...@digitalocean.com:
Today I noticed a ruleset with only stop as it's action will fail to
parse with rsyslog 8.4, but the same rule with a ~ will pass.
ruleset(name=testme) {
*.* ~
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master config
./test.conf
rsyslogd: warning: ~ action is deprecated, consider using the 'stop'
statement instead [try http://www.rsyslog.com/e/2307 ]
Changing to stop :
ruleset(name=testme) {
stop
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master config
./test.conf
rsyslogd: CONFIG ERROR: there are no active actions configured. Inputs
will
run, but no output whatsoever is created. [try
http://www.rsyslog.com/e/2103
]
rsyslogd: run failed with error -2103 (see rsyslog.h or try
http://www.rsyslog.com/e/2103 to learn what that number means)
I have a situation where rules are being generated via templates in
chef,
and having a rule that just discards messages would actually be a useful
thing to have, and ran into this.
So my question is, should a rule that only calls a discard action be
valid? If so, is this a bug in the config parser?
It's a little bit complex. The thing is that ~ actually *is* an
action,
whereas stop is a statement. When I wrote that checking code, I never
envisioned that an empty ruleset could be useful for any case (if there
is
just a stop inside it, it's practically empty, in that it simply does
nothing). I think in most cases this really is a config error. Maybe I
could add an permitEmpty parameter to the ruleset, which will then not
emit that error message.
To understand the whole picture: why do you need these empty rulesets?
Rainer
Brian
___
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
Re: [rsyslog] ruleset with only stop
+1 for permitEmpty=on - it would definitely simplify our lives.
Brian
On Tue, Nov 11, 2014 at 11:40 AM, Boylan, James james.boy...@orbitz.com
wrote:
I think that the permitEmpty=on field is a reasonable starting place. I
have a config management app that I use with rsyslog that this field would
help significantly with.
-- James
--- Sent from my mobile phone ---
- Reply message -
From: Rainer Gerhards rgerha...@hq.adiscon.com
To: rsyslog-users rsyslog@lists.adiscon.com
Subject: [rsyslog] ruleset with only stop
Date: Tue, Nov 11, 2014 10:29 AM
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.
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?
Rainer
David Lang
Brian
On Tue, Nov 11, 2014 at 4:06 AM, Rainer Gerhards
rgerha...@hq.adiscon.com
wrote:
2014-11-10 16:23 GMT+01:00 Brian Knox bk...@digitalocean.com:
Today I noticed a ruleset with only stop as it's action will fail to
parse with rsyslog 8.4, but the same rule with a ~ will pass.
ruleset(name=testme) {
*.* ~
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master
config
./test.conf
rsyslogd: warning: ~ action is deprecated, consider using the 'stop'
statement instead [try http://www.rsyslog.com/e/2307 ]
Changing to stop :
ruleset(name=testme) {
stop
}
bknox@seriamau:~$ rsyslogd -N1 -f ./test.conf
rsyslogd: version 8.5.0, config validation run (level 1), master
config
./test.conf
rsyslogd: CONFIG ERROR: there are no active actions configured. Inputs
will
run, but no output whatsoever is created. [try
http://www.rsyslog.com/e/2103
]
rsyslogd: run failed with error -2103 (see rsyslog.h or try
http://www.rsyslog.com/e/2103 to learn what that number means)
I have a situation where rules are being generated via templates in
chef,
and having a rule that just discards messages would actually be a
useful
thing to have, and ran into this.
So my question is, should a rule that only calls a discard action be
valid? If so, is this a bug in the config parser?
It's a little bit complex. The thing is that ~ actually *is* an
action,
whereas stop is a statement. When I wrote that checking code, I never
envisioned that an empty ruleset could be useful for any case (if there
is
just a stop inside it, it's practically empty, in that it simply does
nothing). I think in most cases this really is a config error. Maybe I
could add an permitEmpty parameter to the ruleset, which will then
not
emit that error message.
To understand the whole picture: why do you need these empty rulesets?
Rainer
Brian
___
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
Re: [rsyslog] ruleset with only stop
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.
Re: [rsyslog] ruleset with only stop
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.
