|Main Archive Page > Month Archives > syslog-ng-users archives|
On 07/14/2011 03:14 PM, Balazs Scheidler wrote:
>> On 07/14/2011 03:16 AM, Balazs Scheidler wrote:
>>> On Sat, 2011-06-25 at 04:49 -0400, JP Vossen wrote:
>>>>> On Mon, 2011-06-20 at 20:59 +0100, Jose Pedro Oliveira wrote:
>>>>>> There is a problem with the hash table implementation of glib2
>>>>>> version 2.12.3-4 (version that ships in RHEL 5.x).
>>>> Is this hash problem going to cause critical failures? Under what
>>>> circumstances? Or is it, well, it'd be nice if that hash problem
>>>> didn't happen, but it's not a big deal...
>>> Well, it probably mostly depends on why the hashtable collides in that
>>> glib version. This hash is a global hash that maps name-value pairs to
>>> their own unique IDs, which is then used to track name-value pairs in
>>> log messages.
>> Sorry if I am being dense. What name-value pairs used for what? Would
>> this impact a basic syslog-ng config that emulates the sysklogd config?
>> What syslog-ng features need to be in use to trigger this?
> For syslog-ng a log message is a set of name-value pairs. Basic
> syslog properties like $HOST or $MSG as well. The only exceptions are
> the $PRI and $DATE fields.
> But syslog-ng uses hash tables for a number of other things, so this
> can cause other bugs as well.
Ouch, that sounds like a show-stopper for using 3.2.x. on un-fixed
RHEL-5/CentOS-5. So I wondered what I can use safely? Or am I
First I tried looking for any '*nvtable*' file, and 3.0.9 has none while
3.1.4 and 3.2.4 have some. But then I looked at
https://bugzilla.redhat.com/show_bug.cgi?id=716447 and started looking
for 'g_hash_table' and that's not too good.
I found lots of hits for 'g_hash_table'  in every version of
syslog-ng I had laying around:
 $ grep -Rc 'g_hash_table' syslog-ng-2.1.4/* syslog-ng-3.0.9/*
syslog-ng-3.1.4/* syslog-ng-3.2.4/* | grep -v ':0$'
Does anyone know what is the latest syslog-ng that can safely be used on
un-fixed RHEL-5/CentOS-5? What is a valid test to look for this problem
(if nvtable files or g_hash_table isn't)?
>>> In case the hash table returns non-matching elements, it means that two
>>> (or more) different name-value pairs will map to the same id,
>>> effectively one overwriting the other. Whether it happens in practice
>>> actually depends on what the exact bug in glib is.
>> Given how old CentOS-5 is, I wonder that this hasn't been noticed and
>> reported before now. Perhaps that means it's rare to hit it in
>> practice? Or maybe just really hard to identify the root cause.
> I think the misbehaviour is difficult to notice, and the root cause is not easy either.
> I've checked the glib history, but I've found no patch that jumped out.
The bug is still open (but also brand new):
JP Vossen, CISSP |:::======| http://bashcookbook.com/
My Account, My Opinions |=========| http://www.jpsdomain.org/
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng