Date: Sun, 12 Jan 1997 19:20:33 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: FreeBSD-gnats-submit@freebsd.org Subject: bin/2469: xntpd(8)'s logging is too blatant Message-ID: <199701121820.TAA00803@uriah.heep.sax.de> Resent-Message-ID: <199701121840.KAA10113@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 2469 >Category: bin >Synopsis: xntpd(8)'s logging is too blatant >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Jan 12 10:40:03 PST 1997 >Last-Modified: >Originator: J Wunsch >Organization: >Release: FreeBSD 3.0-CURRENT i386 >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 >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701121820.TAA00803>