Bug 122790

Summary: ntptrace doesn't show ntp server names
Product: Red Hat Enterprise Linux 4 Reporter: H.J. Lu <hongjiu.lu>
Component: ntpAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: jturner
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-19 09:54:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description H.J. Lu 2004-05-07 21:37:42 UTC
On Fedora 2 test 3, I got

hjl@gnu-64b gnu-20]$ /usr/sbin/ntptrace
gnu-64b.sc.intel.com: stratum 16, offset 0.000000, root distance 0.000000

I am expecting something like

bash-2.05b$ ntptrace
localhost.localdomain: stratum 2, offset 0.000047, synch distance 0.03241
ntp-nasa.arc.nasa.gov: stratum 1, offset -0.002047, synch distance
0.00089, refid 'GPS'

Comment 1 H.J. Lu 2004-05-07 22:00:10 UTC
Apparently, the new one works differently from the old one
where the new one will output

gnu-64b.sc.intel.com: stratum 16, offset 0.000000, root distance 0.000000

if the machine isn't synced yet and old one will wait.

Comment 2 H.J. Lu 2004-06-28 18:20:51 UTC
I have 2 machines on the same network. One is running EL 3 U2 and
the other is running EL 4 A3. On EL 3 U2, I got

[hjl@gnu-20 kernel-EL]$ ntptrace
gnu-20.sc.intel.com: stratum 4, offset 0.000000, synch distance 0.06349
sc127a-hsrp-140.sc.intel.com: stratum 3, offset 0.006058, synch
distance 0.01227
scbc.wan.intel.com: stratum 2, offset 0.000957, synch distance 0.00774
scntpsrv.wan.intel.com:         *Timeout*

On EL 4 A3, I got

[hjl@gnu-64 hjl]$ ntptrace
gnu-64.sc.intel.com: stratum 4, offset -0.040207, root distance 0.007428
143.183.140.251: timed out, nothing received
***Request timed out
[hjl@gnu-64 hjl]$ host 143.183.140.251
251.140.183.143.in-addr.arpa domain name pointer
sc127a-hsrp-140.sc.intel.com.

I believe EL 4 A3 is synced with sc127a-hsrp-140.sc.intel.com. It is
just that ntptrace doesn't show it.

Comment 3 Harald Hoyer 2004-08-27 16:13:23 UTC
is sc127a-hsrp-140.sc.intel.com a router or s.th. like that?

Comment 4 H.J. Lu 2004-10-04 20:49:35 UTC
sc127a-hsrp-140.sc.intel.com is the NTP server on the subnet.

Comment 5 Harald Hoyer 2004-10-05 09:33:28 UTC
yes, I know, but which kind of machine is this? a linux PC?

Comment 6 H.J. Lu 2004-10-05 15:55:59 UTC
I have no idea what kind of machine sc127a-hsrp-140.sc.intel.com is.
FWIW, ntptrace in RHEL 3 U3 works fine with it.

Comment 7 H.J. Lu 2004-10-05 16:06:56 UTC
The new ntptrace in RHEL 4 is a perl script, which uses "ntpq". I got
these on RHEL 3 U3:

[hjl@gnu glibc]$ ntpq sc127a-hsrp-140.sc.intel.com
ntpq> rv
sc127a-hsrp-140.sc.intel.com: timed out, nothing received
***Request timed out
ntpq>
[hjl@gnu glibc]$ ntptrace sc127a-hsrp-140.sc.intel.com
sc127a-hsrp-140.sc.intel.com: stratum 3, offset 0.004291, synch
distance 0.02068sccc.wan.intel.com: stratum 2, offset 0.004002, synch
distance 0.01994
chntpsrv.wan.intel.com:

In the ntpq man page on RHEL 4, there are

The  ntpq  utility program is used to query NTP servers which implement
       the recommended NTP mode 6 control message format about 
current  state
       and  to request changes in that state.

Since this functionality is a recommended feature, a compliant
ntp server may not implement/enable it.


Comment 8 Harald Hoyer 2004-11-29 14:05:53 UTC
so bug or rfe?

Comment 9 H.J. Lu 2004-11-29 18:44:05 UTC
It is a regression from RHEL 3.

Comment 10 Harald Hoyer 2004-11-30 10:39:03 UTC
Ok, posted:
http://bugzilla.ntp.org/show_bug.cgi?id=364

Comment 11 Jay Turner 2005-01-14 14:21:11 UTC
Back in assigned, as we're no longer awaiting information.

Comment 12 Miroslav Lichvar 2010-03-19 09:54:04 UTC
As RHEL-4.9 is the last update for RHEL-4, which should address only security, performance and critical issues, I'm closing this bug as WONTFIX. If you 
are still experiencing this issue with RHEL-5, please reopen it against RHEL-5.

If this issue is critical for you, please contact Red Hat support.