I think that should be doable without too much trouble. I would appreciate a github issue tracker.
Side-Note: I never intended to support general purpose loops, but of course there is always a way to do it ;-) Rainer El sáb, 17 jul 2021 a las 16:17, Mariusz Kruk via rsyslog (<[email protected]>) escribió: > > A wasn't even thinking about testing for calling current ruleset since > it seems overly complicated. > > Just a simple counter increased by one on every call/call_indirect and a > check whether or not it exceeds a given (configurable?) limit. > > But then again - as I said - my use case is quite complicated and the > whole first mail was more of a way to archive the problem since someone > might encounter it on their own and not be able to pinpont the cause > quickly. The case of ruleset looping might be so rare that it's not > worth adding such check. > > Best regards > > MK > > > On 16.07.2021 19:15, David Lang wrote: > > 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. _______________________________________________ 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.
