On Fri, 2006-09-01 at 23:04 +0100, G.W. Haywood wrote:
Hi folks,
Using 2.0rc1 I find lines like this in /var/log/messages:
Sep 1 22:18:32 mail3 by lists.balabit.hu (Postfix) with ESMTP id 83E8A4C117 Sep 1 22:18:32 mail3 for <ged@jubileegroup.co.uk>; Fri, 1 Sep 2006 23:18:17 +0200 (CEST)')<31>Sep 1 22:18:32 milter-regex[20073]: 212.92.18.33: cb_header('MIME-Version', '1.0') Sep 1 22:18:32 mail3 <syslog-ng.lists.balabit.hu>')<31>Sep 1 22:18:32 milter-regex[20073]: 212.92.18.33: cb_header('X-List-Administrivia', 'yes')
Sorry if the three lines above wrap for you. I haven't attempted to break them. They are imported using an editor, not copy-n-paste, so that non-printing characters are reproduced correctly in the mail. Each line above has a tab character after the string "mail3 ", which is the hostname followed by a single space.
There are two problems. First, these lines shouldn't be written to this log at all. Second, some of the lines are being concatenated onto a single line instead of being written to two lines. Instead of three lines above, there should have been five lines. The <facility, priority> info is visible at the points where the lines are joined.
The lines that you see here are produced by a sendmail milter called 'milter-regex' which is supposed to be logging with facility 'daemon' and according to the syslog-ng configuration messages from this milter should not appear in the 'messages' file at all. Most of them don't (milter-regex is producing a _lot_ of output), but mail message header continuation lines do. A log message following a header continuation line is concatenated to it, and the filter doesn't seem to notice it. The lines that incorrectly appear in 'messages' do not appear in the correct file, which is 'mail.milter-regex' in the config below.
Any ideas?
Can you check if this patch fixes the problem (syslog-ng 1.6 and 2.0 had a different behaviour regarding messages received on a datagram transport, this change should move them to unison). This patch only helps if you indeed using datagram transport (unix-dgram or udp()), otherwise it will not change a thing: --- orig/src/logreader.c +++ mod/src/logreader.c @@ -193,7 +193,7 @@ log_reader_handle_line(LogReader *self, * log_reader_iterate_buf: * @self: LogReader instance * @saddr: socket address to be assigned to new messages (consumed!) - * @flush: + * @flush: whether to flush the input buffer * @msg_counter: the number of messages processed in the current poll iteration * **/ @@ -224,14 +224,13 @@ log_reader_iterate_buf(LogReader *self, if (self->flags & LR_LOCAL) parse_flags |= LF_LOCAL; - if (!eol && - ((self->ofs == self->options->msg_size) || - ((self->flags & LR_PKTTERM) && self->ofs) || - self->options->padding || - flush)) + if ((self->flags & LR_PKTTERM) || + (!eol && (self->ofs == self->options->msg_size)) || + self->options->padding || + flush) { /* our buffer is full, or - * we are set to packet terminating mode and there's no terminating new line, or + * we are set to packet terminating mode, or * we are in padded mode HP-UX */ length = (self->options->padding -- Bazsi