(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