patterndb context-timeout problem
Hi, I've found a problem in handling context-timeout in a special case. If context-timeout=10 (10 sec) and I am using a trigger, where trigger="timeout", it can happen that the timeout won't expire: I sent the following two messages to syslog-ng before expiring timeout (but the difference between the two timestamp is bigger than the timeout value): "<38>1990-01-01T14:45:25 customhostname program6[1234]: program6 testmessage" "<38>1990-01-01T14:55:25 customhostname program6[1234]: program6 testmessage" I receive the timeout message immediately, when the second message arrives (it's ok), but there is no timeout for the second message.
On Fri, 2011-03-04 at 10:41 +0100, Zoltán Pallagi wrote:
Hi,
I've found a problem in handling context-timeout in a special case.
If context-timeout=10 (10 sec) and I am using a trigger, where trigger="timeout", it can happen that the timeout won't expire:
I sent the following two messages to syslog-ng before expiring timeout (but the difference between the two timestamp is bigger than the timeout value):
"<38>1990-01-01T14:45:25 customhostname program6[1234]: program6 testmessage" "<38>1990-01-01T14:55:25 customhostname program6[1234]: program6 testmessage"
I receive the timeout message immediately, when the second message arrives (it's ok), but there is no timeout for the second message.
Thanks for the report, it was a really good catch. The unit tests didn't find it, because it is a key in this bug to have the two timestamps so much apart (more precisely, it needs to cross an 1024 second boundary to be triggered). This patch fixes it: commit c3b5518d0c76740a43b192a24f5d9778f4e63282 Author: Balazs Scheidler <bazsi@balabit.hu> patterndb: fixed timerwheel bug that caused timers not to expire Reproduction: - set the current time to 1990-01-01T14:45:25 - add a timer that expires 10 seconds from the above time - before that'd expire, set the current time to 1990-01-01T14:55:25 - add a timer that expires 10 seconds from the 2nd date The cause was that base wasn't properly updated when we break out of the timer advancement loop in timer_wheel_set_time(). Reported-By: Zoltan Pallagi <pzolee@balabit.hu> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> -- Bazsi
participants (2)
-
Balazs Scheidler
-
Zoltán Pallagi