The rocket-fast system for log processing

Changelog for 7.2.4 (v7-stable)

Version 7.2.4 [v7-stable] 2012-12-07

  • enhance: permit RFC3339 timestamp in local log socket messages
    Thanks to Sebastien Ponce for the patch.
  • imklog: added ParseKernelTimestamp parameter (import from 5.10.2)
    Thanks to Marius Tomaschewski for the patch.
  • fix missing functionality: ruleset(){} could not specify ruleset queue
    The "" parameter set was not supported, and legacy ruleset
    config statements did not work (by intention). The fix introduces the
    "" parameter set. It has some regression potential, but only
    for the new functionality. Note that using that interface it is possible
    to specify duplicate queue file names, which will cause trouble. This
    will be solved in v7.3, because there is a too-large regression
    potential for the v7.2 stable branch.
  • imklog: added KeepKernelTimestamp parameter (import from 5.10.2)
    Thanks to Marius Tomaschewski for the patch.
  • bugfix: imklog mistakenly took kernel timestamp subseconds as nanoseconds
    … actually, they are microseconds. So the fractional part of the
    timestamp was not properly formatted. (import from 5.10.2)
    Thanks to Marius Tomaschewski for the bug report and the patch idea.
  • bugfix: supportoctetcountedframing parameter did not work in imptcp
  • bugfix: modules not (yet) supporting new conf format were not properly
    registered. This lead to a "module not found" error message instead of
    the to-be-expected "module does not support new style" error message.
    That invalid error message could be quite misleading and actually stop
    people from addressing the real problem (aka "go nuts" ;))
  • bugfix: template "type" parameter is mandatory (but was not)
  • bugfix: some message properties could be garbled due to race condition
    This happened only on very high volume systems, if the same message was
    being processed by two different actions. This was a regression caused
    by the new config processor, which did no longer properly enable msg
    locking in multithreaded cases. The bugfix is actually a refactoring of
    the msg locking code – we no longer do unlocked operations, as the use
    case for it has mostly gone away. It is potentially possible only at
    very low-end systems, and there the small additional overhead of doing
    the locking does not really hurt. Instead, the removal of that
    capability can actually slightly improve performance in common cases,
    as the code path is smaller and requires slightly less memory writes.
    That probably outperforms the extra locking overhead (which in the
    low-end case always happens in user space, without need for kernel
    support as we can always directly aquire the lock – there is no
    contention at all).