Re: [syslog-ng] syslog-ng under HP-UX processing unwanted "padded" data
(resending as my first attempt didn't make it to the list, apologies if there are duplicates)
If you still think it is, you might want to use tusc to check if syslog-ng reads /dev/log in 2048 byte chunks (which is should if pad_size() is enabled and which it doesn't if it is not).
Most of the time it does, but sometimes it doesn't:
7197: read(4, "< 3 8 > S e p 7 1 0 : 5 2 ".., 8192) = 2048 7197: read(4, 0 <---- snip -----> 7197: read(4, "\0\0\0\0\0< 3 8 > S e p 7 ".., 8192) = 6149 7197: read(4, "< 2 2 > S e p 7 1 0 : 5 5 ".., 8187) = 8187 7197: read(4, "u s . n e ", 8173) = 5 7197: read(4, 0 <---- snip ----->
I have since tried the syslog-ng 1.6.12 package from the HP-UX Porting and Archive Centre again. This version is a little flaky (core dumps on SIGHUP or .conf syntax errors) however when configured correctly it does appear to read the /dev/log device with the correct padding. Therefore it would appear to be more recent enhancements that have changed this behaviour - although I assume at least some people are running syslog-ng v3 successfully under HP-UX. I tried to use gdb to determine whether the padding value in the LogProto object had the expected value of 2048, but... I'm not sure that's the right variable to look at, or even whether I'm doing it correctly, being a gdb newbie. Is there any more information I can provide or tests I can perform to help identify the cause, as I would prefer to use a more recent and hopefully stable version than 1.6 if possible? Regards, Scott
On Fri, 2010-09-10 at 11:53 +1100, Scott Rochford wrote:
(resending as my first attempt didn't make it to the list, apologies if there are duplicates)
If you still think it is, you might want to use tusc to check if syslog-ng reads /dev/log in 2048 byte chunks (which is should if pad_size() is enabled and which it doesn't if it is not).
Most of the time it does, but sometimes it doesn't:
7197: read(4, "< 3 8 > S e p 7 1 0 : 5 2 ".., 8192) = 2048 7197: read(4, 0 <---- snip -----> 7197: read(4, "\0\0\0\0\0< 3 8 > S e p 7 ".., 8192) = 6149 7197: read(4, "< 2 2 > S e p 7 1 0 : 5 5 ".., 8187) = 8187 7197: read(4, "u s . n e ", 8173) = 5 7197: read(4, 0 <---- snip ----->
I have since tried the syslog-ng 1.6.12 package from the HP-UX Porting and Archive Centre again. This version is a little flaky (core dumps on SIGHUP or .conf syntax errors) however when configured correctly it does appear to read the /dev/log device with the correct padding. Therefore it would appear to be more recent enhancements that have changed this behaviour - although I assume at least some people are running syslog-ng v3 successfully under HP-UX.
I tried to use gdb to determine whether the padding value in the LogProto object had the expected value of 2048, but... I'm not sure that's the right variable to look at, or even whether I'm doing it correctly, being a gdb newbie.
Is there any more information I can provide or tests I can perform to help identify the cause, as I would prefer to use a more recent and hopefully stable version than 1.6 if possible?
The proper value to look at is proto->padding_size But if you can use gdb, then you might want to put a breakpoint to logproto.c:541 the line number may be a bit different, depending on your exact version. You should try to locate this line: rc = log_transport_read(self->super.transport, raw_buffer + self->raw_buffer_leftover_size, avail, sa); You should look at the value of the "avail" variable, it should always be 2048. If it isn't 2048, then we'd need to find out why. It is calculated right before the line I've mentioned above, and all branches should set avail to 2048 at the end. -- Bazsi
participants (2)
-
Balazs Scheidler
-
Scott Rochford