[syslog-ng] Messages concatenated on one line in log file.

[Balazs Scheidler]

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[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