From j@uriah.heep.sax.de  Sun Jan 12 10:31:40 1997
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA09450
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 12 Jan 1997 10:31:38 -0800 (PST)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA22040 for FreeBSD-gnats-submit@freebsd.org; Sun, 12 Jan 1997 19:31:36 +0100
Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id TAA00803; Sun, 12 Jan 1997 19:20:33 +0100 (MET)
Message-Id: <199701121820.TAA00803@uriah.heep.sax.de>
Date: Sun, 12 Jan 1997 19:20:33 +0100 (MET)
From: J Wunsch <j@uriah.heep.sax.de>
Reply-To: j@uriah.heep.sax.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: xntpd(8)'s logging is too blatant
X-Send-Pr-Version: 3.2

>Number:         2469
>Category:       bin
>Synopsis:       xntpd(8)'s logging is too blatant
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jan 12 10:40:03 PST 1997
>Closed-Date:    Wed Apr 15 11:39:10 PDT 1998
>Last-Modified:  Wed Apr 15 11:41:12 PDT 1998
>Originator:     J Wunsch
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
>Environment:

xntpd(8) from the base system.

>Description:

Run xntpd(8) with a local refclock.  Since these refclocks are radio
receivers, they tend to drop signal every now and then.  xntpd(8) logs
these events blatantly with a level of LOG_ERR.  Since it also uses
the LOG_DAEMON facility, it's impossible to filter them out from
really important events.  If you run a campus timeserver for 5000
students, this might be important, but in other occasions, the
occasionally breaking clock accuracy is totally unimportant.  The
messages are annoying, and most complaints are even logged twice, with
verbose babble among:

xntpd[189]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits 
xntpd[189]: parse: time format "-#" not convertable 
xntpd[189]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits 
xntpd[189]: parse: time format "-" not convertable 
xntpd[189]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits 
xntpd[189]: parse: time format "-" not convertable 
xntpd[189]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits 
xntpd[189]: parse: time format "##" not convertable 
xntpd[189]: PARSE receiver #0: no data from device within poll interval
xntpd[189]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 3 bits 
xntpd[189]: parse: time format "--#" not convertable 

(Timestamps and hostname removed for brevity, the actual tty looks
even more garbled.)

>How-To-Repeat:

Run xntpd with a local refclock that occasionally fades signal.

>Fix:
	
Either spend a unique syslog facility to xntpd(8), or log with a much
lower priority so normal filtering will work.  People who are really
interested in the messages can still use the `!prog' notation of
syslog.conf to get at their data:

!xtnpd
*.*			root,xxx


>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@lcs.mit.edu>
To: j@uriah.heep.sax.de
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: bin/2469: xntpd(8)'s logging is too blatant
Date: Mon, 13 Jan 1997 11:11:28 -0500

 <<On Sun, 12 Jan 1997 19:20:33 +0100 (MET), J Wunsch <j@uriah.heep.sax.de> said:
 
 > these events blatantly with a level of LOG_ERR.  Since it also uses
 > the LOG_DAEMON facility, it's impossible to filter them out from
 
 I think that if we wanted to assign a facility to NTP and call it
 LOG_NTP, then xntpd would obey.
 
 -GAWollman
 
 --
 Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
 wollman@lcs.mit.edu  | O Siem / The fires of freedom 
 Opinions not those of| Dance in the burning flame
 MIT, LCS, ANA, or NSA|                     - Susan Aglukark and Chad Irschick
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Wed Apr 15 11:39:10 PDT 1998 
State-Changed-Why:  
Our current syslogd allows you to handle things "per daemon", but I would 
tend to think that this level of verbosity (which only the DCF77 parse driver 
is guilty of) belongs in the ntp clockstats file rather than syslog. 
ntp is a future "contrib" target, and I suggest you take it up with 
the people at the far end of http://www.eecis.udel.edu/~ntp 
>Unformatted:
