Re: Messages concatenated on one line in log file.
Balazs Scheidler <bazsi <at> balabit.hu>
2006-09-04 10:18:46 GMT
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 <at> jubileegroup.co.uk>; Fri, 1 Sep 2006 23:18:17 +0200 (CEST)')<31>Sep 1
22:18:32 milter-regex: 126.96.36.199: 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:
188.8.131.52: 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:
<at> <at> -193,7 +193,7 <at> <at> log_reader_handle_line(LogReader *self,
* <at> self: LogReader instance
* <at> saddr: socket address to be assigned to new messages (consumed!)
- * <at> flush:
+ * <at> flush: whether to flush the input buffer
* <at> msg_counter: the number of messages processed in the current poll iteration
<at> <at> -224,14 +224,13 <at> <at> 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 ||
+ if ((self->flags & LR_PKTTERM) ||
+ (!eol && (self->ofs == self->options->msg_size)) ||
+ self->options->padding ||
/* 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
syslog-ng maillist - syslog-ng <at> lists.balabit.hu
Frequently asked questions at http://www.campin.net/syslog-ng/faq.html