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

Balazs Scheidler bazsi at balabit.hu
Mon Sep 6 10:16:24 CEST 2010


On Mon, 2010-09-06 at 16:58 +1100, Scott Rochford wrote:
> 
> Hi, 
> 
> I'm trying to test syslog-ng under HP-UX 11iv2 (both PA-RISC and IA64)
> to use as an alternative to the supplied syslogd. 
> 
> I have tried using the precompiled 3.0.5 binaries supplied with HP's
> DSAU (Distributed Systems Administration Utilities) pack, as well as
> compiling 3.0.5 and also version 3.1.2 from source.  In all 3 cases I
> have the same problem; it seems to be attempting to process the padded
> data remaining in the 2048-byte chunk that is read from /dev/log, as
> you can see from the test below.  In other words it does not stop
> processing the 2048-byte chunk of data when it reaches the first null
> byte.  This means that the first log entry after startup is processed
> correctly, but then all sorts of random things start to happen,
> including blank (other than date stamp and host name) messages to
> every connected terminal. 
> 
> I used gcc-3.4.3, glib-2.24.2, popt 1.16, and pkgconfig 0.25 from the
> HP-UX Porting and Archive Centre to compile it. 
> 
> Have I overlooked something obvious here?  I can't see any other
> similar reports on this mailing list or in the wild. 
> 
> I'd appreciate any suggestions!  Regards, 
> 
> Scott. 
> 
> P.S. It's a little confusing that the HP-UX notes in the INSTALL file
> and the contrib/syslog-ng.conf.HP-UX files disagree with each other
> about the source syntax; will these be reconciled in a future
> release? 
> 

Well, contrib is what the directory says, contributed stuff, but I don't
really maintain them. It'll probably be removed from the tarball as it
causes confusions like this.


> # default contrib'd version 
> # source s_sys { pipe("/dev/log"); internal(); }; 
> 
> # recommended by INSTALL 
> source s_sys { pipe("/dev/log" pad_size(2048)); }; 

This should be the proper source statement. I've just retested it on our
local HP-UX box and it seems to work fine.

The things you are experiencing seems to indicate that the pad_size()
option is missing, therefore I'd like to ask if you are certain that
syslog-ng is running with the pad_size() configuration.

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).

-- 
Bazsi



More information about the syslog-ng mailing list