syslog-ng under HP-UX processing unwanted "padded" data
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? # nohup /usr/local/sbin/syslog-ng --debug --foreground --stderr > syslog-ng.out 2>&1 & # logger -p user.notice "a user.notice test" # grep Incoming syslog-ng.out | head Incoming log entry; line='<13>Sep 6 05:16:52 syslog: a user.notice test' Incoming log entry; line='L\x84yD' Incoming log entry; line='\x01' Incoming log entry; line='\x01' Incoming log entry; line='\x01' Incoming log entry; line='\x09' Incoming log entry; line='\x01\x90T' Incoming log entry; line='\xd1\x9d' Incoming log entry; line='h\x0f\x1c,h\x0f\x1c\x98@' Incoming log entry; line='[Hh\x0dG\xc4h\x0dG\xc4\xc0\x1d?K\xc0\x1d?\x93' # /usr/local/sbin/syslog-ng -V syslog-ng 3.1.2 Installer-Version: 3.1.2 Revision: ssh+git://bazsi@git.balabit//var/scm/git/syslog-ng/syslog-ng-ose--mainline--3.1#master#8bf13c304b6ab5fc1a372b49d55c78370efe14ca Compile-Date: Sep 6 2010 01:21:23 Enable-Threads: off Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-Sun-STREAMS: off Enable-Sun-Door: off Enable-IPv6: on Enable-Spoof-Source: off Enable-TCP-Wrapper: on Enable-SSL: on Enable-SQL: off Enable-Linux-Caps: off Enable-Pcre: off # cat /usr/local/etc/syslog-ng.conf @version: 3.0 # syslog-ng configuration file. # # This should behave pretty much like the original syslog on HP-UX. But # it could be configured a lot smarter. # # See syslog-ng(8) and syslog-ng.conf(8) for more information. # # 20000925 gb@sysfive.com options { time_reopen (10); log_fifo_size (1000); long_hostnames (off); use_dns (no); use_fqdn (no); create_dirs (no); keep_hostname (yes); }; # default contrib'd version # source s_sys { pipe("/dev/log"); internal(); }; # recommended by INSTALL source s_sys { pipe("/dev/log" pad_size(2048)); }; destination d_cons { file("/dev/console"); }; destination d_mesg { file("/var/adm/syslog/syslog.log"); }; destination d_mail { file("/var/adm/syslog/mail.log"); }; destination d_mlrt { usertty("root"); }; destination d_mlal { usertty("*"); }; filter f_filter1 { facility(mail) and level(debug); }; filter f_filter2 { (facility(mail) and level(debug)) or level(info); }; filter f_filter3 { level(alert); }; filter f_filter4 { level(emerg); }; log { source(s_sys); filter(f_filter1); destination(d_mail); }; log { source(s_sys); filter(f_filter2); destination(d_mesg); }; log { source(s_sys); filter(f_filter3); destination(d_cons); destination(d_mlrt); }; log { source(s_sys); filter(f_filter4); destination(d_mlal); }; #
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
Apologies for my broken email client, which shall remain nameless!
# 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.
Yep, it definitely appears to be opening the configuration file that I'm playing with: # nohup /opt/tusc/bin/truss -o /tmp/syslog-ng.truss -aef /usr/local/sbin/syslog-ng --debug --foreground --stderr > syslog-ng.out 2>&1 & # grep syslog-ng.conf /tmp/syslog-ng.truss 7197: open("/usr/local/etc/syslog-ng.conf", O_RDONLY|O_LARGEFILE, 0666) = 4 #
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, 0x40025dbd, 8187) ERR#11 EAGAIN 7197: read(4, "< 2 8 > S e p 7 1 0 : 5 3 ".., 8187) = 2048 7197: read(4, "< 2 7 > S e p 7 1 0 : 5 3 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN 7197: read(4, "< 2 2 > S e p 7 1 0 : 5 4 ".., 8192) = 4096 7197: read(4, "< 2 2 > S e p 7 1 0 : 5 4 ".., 8187) = 2048 7197: read(4, 0x40025dbd, 8187) ERR#11 EAGAIN 7197: read(4, "< 2 2 > S e p 7 1 0 : 5 4 ".., 8187) = 2048 7197: read(4, 0x40025dbd, 8187) ERR#11 EAGAIN 7197: read(4, "< 3 8 > S e p 7 1 0 : 5 5 ".., 8187) = 8187 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, "< 2 8 > S e p 7 1 0 : 5 5 ".., 8168) = 2048 7197: read(4, "< 2 7 > S e p 7 1 0 : 5 5 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN 7197: read(4, "< 2 8 > S e p 7 1 0 : 5 7 ".., 8192) = 2048 7197: read(4, "< 2 7 > S e p 7 1 0 : 5 7 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN 7197: read(4, "< 2 8 > S e p 7 1 0 : 5 9 ".., 8192) = 2048 7197: read(4, "< 2 7 > S e p 7 1 0 : 5 9 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN 7197: read(4, "< 3 8 > S e p 7 1 1 : 0 0 ".., 8192) = 2048 7197: read(4, "< 3 8 > S e p 7 1 1 : 0 0 ".., 8192) = 8192 7197: read(4, "< 3 8 > S e p 7 1 1 : 0 0 ".., 8192) = 8192 7197: read(4, "< 3 8 > S e p 7 1 1 : 0 0 ".., 8192) = 8192 7197: read(4, "< 2 2 > S e p 7 1 1 : 0 0 ".., 8192) = 8192 7197: read(4, "< 2 2 > S e p 7 1 1 : 0 0 ".., 8187) = 8187 7197: read(4, "\0\0\0\0\0", 8192) = 5 7197: read(4, "< 2 8 > S e p 7 1 1 : 0 1 ".., 8192) = 2048 7197: read(4, "< 2 7 > S e p 7 1 1 : 0 1 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN Regards, Scott
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 Tue, 2010-09-07 at 22:05 +1100, Scott Rochford wrote:
Apologies for my broken email client, which shall remain nameless!
# 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.
Yep, it definitely appears to be opening the configuration file that I'm playing with:
# nohup /opt/tusc/bin/truss -o /tmp/syslog-ng.truss -aef /usr/local/sbin/syslog-ng --debug --foreground --stderr > syslog-ng.out 2>&1 & # grep syslog-ng.conf /tmp/syslog-ng.truss 7197: open("/usr/local/etc/syslog-ng.conf", O_RDONLY|O_LARGEFILE, 0666) = 4 #
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, 0x40025dbd, 8187) ERR#11 EAGAIN 7197: read(4, "< 2 8 > S e p 7 1 0 : 5 3 ".., 8187) = 2048 7197: read(4, "< 2 7 > S e p 7 1 0 : 5 3 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN 7197: read(4, "< 2 2 > S e p 7 1 0 : 5 4 ".., 8192) = 4096 7197: read(4, "< 2 2 > S e p 7 1 0 : 5 4 ".., 8187) = 2048 7197: read(4, 0x40025dbd, 8187) ERR#11 EAGAIN 7197: read(4, "< 2 2 > S e p 7 1 0 : 5 4 ".., 8187) = 2048 7197: read(4, 0x40025dbd, 8187) ERR#11 EAGAIN 7197: read(4, "< 3 8 > S e p 7 1 0 : 5 5 ".., 8187) = 8187 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, "< 2 8 > S e p 7 1 0 : 5 5 ".., 8168) = 2048 7197: read(4, "< 2 7 > S e p 7 1 0 : 5 5 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN 7197: read(4, "< 2 8 > S e p 7 1 0 : 5 7 ".., 8192) = 2048 7197: read(4, "< 2 7 > S e p 7 1 0 : 5 7 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN 7197: read(4, "< 2 8 > S e p 7 1 0 : 5 9 ".., 8192) = 2048 7197: read(4, "< 2 7 > S e p 7 1 0 : 5 9 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN 7197: read(4, "< 3 8 > S e p 7 1 1 : 0 0 ".., 8192) = 2048 7197: read(4, "< 3 8 > S e p 7 1 1 : 0 0 ".., 8192) = 8192 7197: read(4, "< 3 8 > S e p 7 1 1 : 0 0 ".., 8192) = 8192 7197: read(4, "< 3 8 > S e p 7 1 1 : 0 0 ".., 8192) = 8192 7197: read(4, "< 2 2 > S e p 7 1 1 : 0 0 ".., 8192) = 8192 7197: read(4, "< 2 2 > S e p 7 1 1 : 0 0 ".., 8187) = 8187 7197: read(4, "\0\0\0\0\0", 8192) = 5 7197: read(4, "< 2 8 > S e p 7 1 1 : 0 1 ".., 8192) = 2048 7197: read(4, "< 2 7 > S e p 7 1 1 : 0 1 ".., 8187) = 4096 7197: read(4, 0x40025db8, 8192) ERR#11 EAGAIN
this tusc trace basically proves that syslog-ng is NOT in pad_size mode, if it were it would issue exactly 2048 byte sized reads whereas it does about 8k reads (probably your log_msg_size is set to 8192), the default. It should look like this (this is actually a PE testbox, but the OSE should be the same): read(5, "< 1 3 > S e p 1 2 1 4 : 5 9 ".., 2048) ............................................................. = 2048 But the same should happen on my Linux testbox, here with OSE 3.1.2, strace: read(6, "alma"..., 2048) = 2048 So for some reason it doesn't process the pad_size() argument. -- Bazsi
this tusc trace basically proves that syslog-ng is NOT in pad_size mode, if it were it would issue exactly 2048 byte sized reads whereas it does about 8k reads (probably your log_msg_size is set to 8192), the default.
So for some reason it doesn't process the pad_size() argument.
Well, I have tried to put debugging statements in suitable places in the code, but I've learnt nothing about why it is not being set. Should I be looking at the logproto->padding-size or the logreader-> options->padding option? Do they refer to different things? Ideally I'd like to print it out at the configuration parsing step, but I can make neither head nor tail of all the bison/yacc/flex stuff that it uses, and can't figure out where to put any debugging statements or breakpoints to determine what's going on. If you could please post a known good configuration file for HP-UX it would help me eliminate anything funny in the one I'm using, which looks fine to the naked eye... Regards, Scott
participants (2)
-
Balazs Scheidler
-
Scott Rochford