a simple test to prevent calling the current ruleset seems like it ould be
doable, but when you start talking chains of rulesets, tracking the full depth
to prevent more indirect loops may be more difficult (or it may not be, Rainer
would need to comment on this)
I think it would be reasonable to have the default be 'no recursion', only allow
calling a ruleset once, with a possible config option to allow a configurable
recursion depth.
when the depth is exceeded, I would have rsyslog log a message and treat the
call as a noop (the other possible option would be to treat it as a stop), and
it would be fantastic if there was a 'bad logs' file that could be defined that
we could have messages that trigger bad things like this written to (in json
format with all metadata, etc) for debugging purposes
David Lang
On Fri, 16 Jul 2021, Mariusz Kruk via rsyslog
wrote:
Date: Fri, 16 Jul 2021 14:23:32 +0200
From: Mariusz Kruk via rsyslog <[email protected]>
To: [email protected]
Cc: Mariusz Kruk <[email protected]>
Subject: [rsyslog] Segfault after recursion too deeply
Hi there.
Just as an interesting fact, after a recent change in configuration I
started receiving segfaults.
segfault at 7fb3ed112ff8 ip 00007fb4323946fe sp 00007fb3ed113000 error 6
in libfastjson.so.4.2.0[7fb432392000+a000]
After some digging I pinpointed the culprit (but I must say that the
origin of the segfault - libfastjson was puzzling here).
My configuration is relatively complicated (over 6,5k lines, including
lookups) so I won't go into much detail here but the main thing is that
in the course of message processing I do a lookup on a specific part of
the message to decide which ruleset to run. Something like this:
ruleset(name="do_a_lookup")
{
set $.ruleset = lookup ("hostname-to-ruleset", $fromhost-ip);
call_indirect $.ruleset;
}
And unfortunately for some messages my lookup returned a "do_a_lookup"
ruleset name to run again and again (of course, since between subsequent
calls the origin of the message didn't change).
It was definitely my mistake and I was quite lucky that it occured quite
quickly after I introduced the change (if it happened with messages I
get just once a day or even once a week, it'd be very hard to troubleshoot).
You might want to think about a ruleset call "depth counter" in order to
at least emit a warning if the recursion gets too deep. But then again -
my case is very unusual and it might not be worth introducing such
change into the code.
Best regards
_______________________________________________
rsyslog mailing list
https://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.
