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