Ra - filter syntax error
elof2 at sentor.se
elof2 at sentor.se
Mon Jun 1 09:09:37 EDT 2015
Hi Carter!
This issue is still present.
If the machine is old and choked, and you feed a *long* filterstring to
'ra', it will take too long to compile.
I think you have already "fixed" this by upping the timeout value.
However, if a machine still have problems compiling the filter in time,
the syslog errormessage looks like this:
2015-06-01 14:47:15 +02:00 foobar ra[99894]: 1433162835.705860 several hundred bytes of filter string
The syslog errormessage is then truncated in the middle of the filter
string, so the end of the string, including the error message, is
never shown.
1)
It seems your patch below is not yet committed?
2)
Could you please also print a unique error message if the filter didn't
compile in time?
Currently it is very misleading that the errormessage says "syntax error"
when the syntax is perfectly fine. Users should be debugging the
performance of the machine, not be fooled into debugging the syntax of the
filter.
If the filter fail to compile in time, the message should be something like:
ArgusLog (LOG_ERR, "filter compilation timeout (took >%d.%d seconds): %s",
wait.tv_sec, wait.tv_usec, ...
/Elof
On Mon, 26 Jan 2015, elof2 at sentor.se wrote:
>
> Actually, my error is not a syntax error - I use the same filter in a cronjob
> every 5 minutes. Only sometimes, like once in three weeks, I get the error
> below.
>
> So there's nothing wrong with the syntax, but I suspect that the filter
> compilation sometimes takes too long, and that this somehow triggers the
> "filter syntax error" when it should trigger a timeout error instead.
> (I haven't had time to recompile and test yet, to verify)
>
>
> If you put the errormessage first, no truncation is needed I think.
> If syslogd has a maximum messagesize, then *it* will truncate instead but we
> will still see the actual error message.
>
> /Elof
>
>
> On Thu, 22 Jan 2015, Carter Bullard wrote:
>
>> Hey /Elof,
>> Error messages where the filter comes before the error type,
>> are all syntax errors, and are found in the ./common/argus_util.c
>> file.
>>
>> Try this patch to move the filter to the end of the error messages …
>>
>> ==== //depot/argus/clients/common/argus_util.c#390 -
>> /Volumes/Users/carter/argus/clients/common/argus_util.c ====
>> 1553c1553
>> < ArgusLog (LOG_ERR, "%s filter syntax error",
>> parser->ArgusRemoteFilter);
>> ---
>>> ArgusLog (LOG_ERR, "filter syntax error: %s",
>>> parser->ArgusRemoteFilter);
>> 1557c1557
>> < ArgusLog (LOG_ERR, "%s filter syntax error",
>> parser->ArgusLocalFilter);
>> ---
>>> ArgusLog (LOG_ERR, "filter syntax error: %s",
>>> parser->ArgusLocalFilter);
>> 1561c1561
>> < ArgusLog (LOG_ERR, "%s filter syntax error",
>> parser->ArgusDisplayFilter);
>> ---
>>> ArgusLog (LOG_ERR, "filter syntax error: %s",
>>> parser->ArgusDisplayFilter);
>>
>>
>> If we truncated the string length, say using %.xxxs where xxx is the number
>> of bytes,
>> what do you think would be a good length ???
>>
>> Carter
>>
>>> On Jan 22, 2015, at 12:14 PM, elof2 at sentor.se wrote:
>>>
>>>
>>> Apropos this old thread.
>>>
>>> If ra 3.0.8 still take too long to compile the filter, the logged message
>>> should be cropped.
>>> Currently, my *long* filter is more than 992 characters, and apparently
>>> that is some limit. Either in ra or in syslog, because the syslog message
>>> looks like this:
>>>
>>> "2015-01-22 15:54:33 +01:00 foobar ra[36131]: 1421938473.058216 src net
>>> (10.0.0.0/8 or ... or ... ... .. . . . . . . . . . and not host
>>> 10.123.123.100 and not host 10.123.123.123 and not host"
>>>
>>> Where the message is 992 characters long.
>>>
>>> In reality it should continue with more "and not host" and after that
>>> probably give some error-message about the filer compilation taking too
>>> long. However, this information is not shown due to the length of my
>>> *long* filterstring.
>>> So, either crop the filterstring, or put the error-message in front of the
>>> filterstring so that people understand why ra is complaining.
>>>
>>> /Elof
>>>
>>>
>>> On Mon, 20 May 2013, Carter Bullard wrote:
>>>
>>>> Hey Elof,
>>>> Great, and thanks for the info. While the clients will be blocked
>>>> waiting for the filter to be compiled, because this is structured as a
>>>> deadman timer, if the compiler returns quickly, there won't be any delay.
>>>>
>>>> For remote accesses, we don't connect until we've compiled the filter.
>>>> The logic is if we can't compile the filter, the remote won't be able to
>>>> either...so a long time wait for the local compiler won't over run us
>>>> with data.
>>>>
>>>> I'll make it 1sec in the code base until I hear otherwise.
>>>> Carter
>>>>
>>>>
>>>> On May 20, 2013, at 7:41 AM, elof2 at sentor.se wrote:
>>>>
>>>>>
>>>>> Carter and I have discussed a very unusual error message; "filter syntax
>>>>> error", which may show up if the machine is HEAVILY burdened, like
>>>>> swapping a lot and/or receiving tons of interrupts, while feeding a long
>>>>> and complex filter expression to a ra* process.
>>>>>
>>>>>> I haven't seen this problem before, but there maybe a simple fix.
>>>>>> In order to get around a problem with using flex and bison to compile
>>>>>> multiple filters at a time, we fork a process to compile a filter, and
>>>>>> wait
>>>>>> for that process to write the filter back to argus through a pipe. We
>>>>>> have specific error messages for the pipe creation, but we use a
>>>>>> generic syntax error message if the forked process doesn't
>>>>>> return a binary filter back to us in a timeout period, which is now set
>>>>>> at 200 milliseconds.
>>>>>
>>>>> I suggest that Carter add a specific error message for this particular
>>>>> scenario, logging the message "filter compilation timeout" instead of
>>>>> the generic "filter syntax error".
>>>>>
>>>>>> In the argus-clients file ./common/argus_code.c, in the routine
>>>>>> ArgusFilterCompile(),
>>>>>> on line 389, we set the timer value. Increase the time to, what, a
>>>>>> second ?
>>>>>> Here is a patch for the 3.0.6.2 code…..
>>>>>> thoth:common carter$ diff argus_code.c.orig argus_code.c
>>>>>> 389,390c389,390
>>>>>> < wait.tv_sec = 0;
>>>>>> < wait.tv_usec = 200000;
>>>>>> ---
>>>>>>> wait.tv_sec = 1;
>>>>>>> wait.tv_usec = 0;
>>>>>
>>>>>
>>>>> During the weekend I've had cron start ra with a long and complex filter
>>>>> string every 5 minutes.
>>>>> With a timeout of 500ms, I had 9 "filter syntax error" in 34 hours.
>>>>> (on an old Intel Xeon 3050 @ 2.13GHz machine from 2008)
>>>>> (with 200ms I suspect I would have had approx 300 warnings)
>>>>>
>>>>>
>>>>> So to prevent this message to appear "too often" on choked machines, you
>>>>> could increase the wait.tv_usec to 750000 ...or even higher if a higher
>>>>> value doesn't introduce any overall negative impact on ra*.
>>>>>
>>>>>
>>>>>
>>>>> I now upped the timeout to 900000 just to see if that is enough to quell
>>>>> even those 9 warnings.
>>>>>
>>>>> /Elof
>>
>
More information about the argus
mailing list