NetBSD Problem Report #1039

From gnats  Tue May  9 20:06:32 1995
Received: from pain.lcs.mit.edu (pain.lcs.mit.edu [128.52.46.239]) by sun-lamp.cs.berkeley.edu (8.6.10/8.6.10) with ESMTP id UAA02746 for <gnats-bugs@sun-lamp.cs.berkeley.edu>; Tue, 9 May 1995 20:06:19 -0700
Message-Id: <199505092214.AAA03305@darling.idt.unit.no>
Date: Wed, 10 May 1995 00:14:47 +0200
From: jarle@idt.unit.no
Reply-To: jarle@idt.unit.no
To: gnats-bugs@NetBSD.ORG
Subject: syslogd occasionally mangles the priority of a forwarded message
X-Send-Pr-Version: 3.2

>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
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 09 20:20:02 +0000 1995
>Closed-Date:    Sun May 14 04:17:56 +0000 1995
>Last-Modified:  
>Originator:     Jarle Greipsland
>Release:        1.0A (sources from April 8th 1995)
>Organization:
"Department of Tautological Pleonasms and Superfluous Redundancies Department"
>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
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: cgd 
State-Changed-When: Sat May 13 21:17:56 PDT 1995 
State-Changed-Why:  
fixed (slightly) differently. 
>Unformatted:

Home	PR Database Search