[syslog-ng] syslog-ng under HP-UX processing unwanted "padded" data

[Balazs Scheidler]

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