Thanks for the confirmation... I guessed as much. Thanks!!! Robert
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavel Levshin Sent: Friday, October 25, 2013 8:32 AM To: [email protected] Subject: Re: [rsyslog] Another approach to action load balancing These numbers are approximately 2^64. It is a bit too long for signed long long, which is used in rsyslog. So wrong results are expected, but at least they are consistent. -- Pavel Levshin 25.10.2013 19:22, Robert McIntyre: > Yes, there does appear to be an issue... Regarding: > > 1- Match/sub-match starting with 0: This isn't a problem; it's documented, etc., and I just missed it. > > 2- I'm putting this in place today, with the proper escaping. > > 4- This was just a learning point for me, not necessarily something to change. > > 3- Type conversions or modulus with big numbers: > > This one is a bit more concerning. I just did a test with setting a string variable to a large numeric string, followed by setting another variable to the mod 5 of that number, and printed both out in a file: > > ... > > template( > name="common1" > type="string" > string="%$!%_\n" > ) > > set $!msgid = "18446744072308350743"; > set $!msgidmod = $!msgid % 5; > > action(name="Act_File6" > type="omfile" > template="common1" > file="/syslogdata/testing/6.txt") > > ... > > And this is the output I get: > { "msgid": "18446744072308350743", "msgidmod": 2 }_ > > Which is incorrect to begin with. But, even more damning is when I increment the string by 1 (making it 18446744072308350744) I get the same result: > { "msgid": "18446744072308350744", "msgidmod": 2 }_ > > Or, if I then switch to mod 3, I get this, which is also wrong (it should be zero): > { "msgid": "18446744072308350744", "msgidmod": 1 }_ > > > But, if I drop down into smaller numbers (255, 256, 257, 258), I get the correct results. So, something is definitely not right when you get to larger numbers. I'm not sure whether it's a problem with the string to number conversion, or the modulus, or something else. > > Thanks! > Robert > >> Date: Fri, 25 Oct 2013 08:05:07 +0200 >> From: [email protected] >> To: [email protected] >> Subject: Re: [rsyslog] Another approach to action load balancing >> >> On Fri, Oct 25, 2013 at 7:51 AM, Pavel Levshin <[email protected]> wrote: >> >>> 25.10.2013 9:30, Robert J. McIntyre: >>> >>> Probably the last email on this, I swear! :) I've had a chance to >>> do a >>>> bunch of digging around, and here's some thoughts/notes on why this >>>> was so weird for me to get sorted out: >>>> >>>> >>>> 1. Match and sub-match for re_extract() start with 0, not 1, which >>>> is >>>> noted in the docs, but didn't register initially >>>> >>> Match numbering had been not obvious to me, too. For submatch, it is >>> natural, as "0" is the whole match, and real submatches are numbered from 1! >> >> I think this was for consistency with the property replacer, but I >> won't even check as it is too late to change now. But I agree to your >> argument ;) >> >> >>> >>> 2. Re_extract doesn't like the typical IP regex (eg. >>>> \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{**1,3}), it didn't seem to like the >>>> escape "\" >>>> characters, so I wound up having to use [0-9]{1,3} and so forth. >>>> It works, but not sure why the escaped characters didn't work. >>>> (Unless I needed to escape the escape characters because it's in a >>>> string, which makes my head hurt; hrrm.) >>>> >>> re_extract is using POSIX Extended Regular Expressions, but escaped >>> symbols are a part of Perl-compatible Regular Expressions. Which is >>> not supported. It worth mentioning in the documentation. >>> >>> >> I think the reason is much simpler. \ is the escape within rsyslog >> strings (to do things like \n). So if you need a \ inside the regex >> (which is given inside the string), you need to escape that escape. >> >> In other words, "\d{1,3}" will lead to "d{1,3}" being passed to the >> regex processor, what you really wanted was "\\d{1,3}" (obviously, >> it's the same in all languages that use \ as escape - just think C for example). >> >> >>>> 3. Cnum(), or the "type-less" conversion, (probably, can't check the >>>> sources) uses longs, which means that really long sequence/serial >>>> numbers from firewalls cause it to overload and do weird things >>>> which make modulus also weird. >>>> >>> This should not be. Cnum is using 'long long'. Have you seen any >>> signs of a bug here? >>> >>> >> +1 >> >>> >>>> 4. Doing type-less comparisons leaves me wondering whether they're >>>> not >>>> evaluating properly, or whether the problem lies upstream when >>>> things don't work properly. The $.msgid == "2" vs. $.msgid == 2 >>>> thing left me uncertain what was correct for a while. >>>> >>> Maybe this is much better in 7.5. >>> >>> >> No, and to be honest I think this is the same "problem" in all >> typeless languages. But I didn't want to introduced the "overhead" of >> a fully type languge. After all, it's still a config file format >> that's deemed to be somewhat flexible. >> >> Nevertheless suggestions are welcome. but note that we cannot break >> what works currently. >> >> Rainer >> >>> -- >>> Pavel Levshin >>> >>> >>> ______________________________**_________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adi >>> scon.net/mailman/listinfo/rsyslog> >>> http://www.rsyslog.com/**professional-services/<http://www.rsyslog.c >>> om/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.
