Subject: bin/1039: syslogd occasionally mangles the priority of a forwarded message
To: None <gnats-admin@sun-lamp.cs.berkeley.edu>
From: None <jarle@idt.unit.no>
List: netbsd-bugs
Date: 05/09/1995 20:20:04
>Number:         1039
>Category:       bin
>Synopsis:       syslogd occasionally mangles the priority of a forwarded message
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May  9 20:20:02 1995
>Originator:     Jarle Greipsland
>Organization:
"Department of Tautological Pleonasms and Superfluous Redundancies Department"
>Release:        1.0A (sources from April 8th 1995)
>Environment:
	
System: NetBSD darling.idt.unit.no 1.0A NetBSD 1.0A (DARLING) #17: Wed Apr 26 13:08:40 MET DST 1995 jarle@darling.idt.unit.no:/usr/src/sys/arch/i386/compile/DARLING i386


>Description:

When syslogd is set up to forward one or several classes of log messages to
a loghost it will occasionally forward a message with an incorrect
priority/facility code.  More specifically, a "to be forwarded" message
that is too big for the 'repeated n times' treatment will be sent with the
priority code of the most recently logged message, forwarded or not, that
was short enough to be elegible for the 'repeated n times' treatment.  This
happens because syslogd first calculate the real priority/facility code in
printline() and then uses it to determine if a message should be logged to
a given destination "file" in logmsg().  Inside fprintlog(), which is
called to do the actual printing, the priority is no longer available and
the only case where it is needed is for remote logging.  fprintlog() then
choose to rely on f->f_prevpri, which will have been correctly set if the
message is short enough to considered for the 'repeated n times' trick.
Otherwise it will be a leftover value from any previous activity/message.

Although I've marked this bug as a low priority one, it certainly scores
high on the annoyance scale...  It seems that some activity internal to
syslogd flushes the log memory and zeros the stashed priority code.  This
makes the loghost interpret the received message as a kern.emerg message
and splatter the message across the terminals of all logged in users.

>How-To-Repeat:
Set up a system to relay log messages to a remote loghost.  Wait until
users complain about spurious messages on their screens......

>Fix:

*** syslogd.c.orig	Tue May  9 13:08:02 1995
--- syslogd.c	Tue May  9 13:08:49 1995
***************
*** 560,563 ****
--- 560,564 ----
  				f->f_prevline[0] = 0;
  				f->f_prevlen = 0;
+ 				f->f_prevpri = pri;
  				fprintlog(f, flags, msg);
  			}

					-jarle
----
"The '#pragma' command is specified in the ANSI standard to have an arbitrary
 implementation-defined effect. In the GNU C preprocessor '#pragma' first
 attempts to run the games 'rogue'; if that fails, it tries to run the game
 'hack'; if that fails, it tries to run GNU Emacs displaying the tower of
 Hanoi; if that fails, it reports a fatal error. In any case, preprocessing
 does not continue."
			-- Manual for the GNU C preprocessor for GNU CC 1.34
>Audit-Trail:
>Unformatted: