Balazs Scheidler <bazsi@balabit.hu> - Fri, Mar 05, 2004:
Check the raw byte-stream as it is sent by the Perl module, I might help to recognize the culprit.
I straced my standard syslogd on my Linux box and saw: recv(0, "<78>fm/logparse: F001|1078750293"..., 1022, 0) = 87 on the unix socket /dev/log. You see "fm/logparse", my program's name, and "F001|1078...", the message. I also captured some udp datagrams from the same Perl configured with 'udp' instead of unix, and got: <78>fm/logparse: F001|10785074... in the payload of the udp datagram. Then I've setup my syslogd to do udp broadcasting, and used "logger -p cron.info -t mytag tagada", captured with ethereal, and got: <78>mytag: tagada... in the udp datagram. The strace for a -p local7.info showed: recv(0, "<190>mar 8 14:02:44 mytag: taga"..., 1022, 0) = 34 sendto(18, "<190>mytag: tagada\n", 19, 0, {sa_family=AF_INET, sin_port=htons(514), sin_addr=inet_addr("192.168.1.15")}, 16) = 19 I attach the whole udp payload of a perl generated udp datagram as "perl-udp.raw". I found no way to capture unix socket traffic, despite my attempts at using "socat", it seems it can't listen() to type 2 sockets (datagram under Linux). I also attach a syslogd generated datagram as "syslogd-udp.raw". AFAICT, it seems the beginning of an udp packet encodes the facility and priority with: - the '<' char; - the hexadecimal digits of the bits for facility and level of the message in ascii; - the '>' char. The only way I found to distinguish Perl generated datagrams from syslogd generated datagrams is the trailing zero. Do you think it is the cause of my troubles? Where could I gather additional data? Regards, -- Loïc Minier <lool@dooz.org>