Bug 122790 - ntptrace doesn't show ntp server names
ntptrace doesn't show ntp server names
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ntp (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-07 17:37 EDT by H.J. Lu
Modified: 2010-03-19 05:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-19 05:54:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description H.J. Lu 2004-05-07 17:37:42 EDT
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 18:00:10 EDT
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 14:20:51 EDT
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 12:13:23 EDT
is sc127a-hsrp-140.sc.intel.com a router or s.th. like that?
Comment 4 H.J. Lu 2004-10-04 16:49:35 EDT
sc127a-hsrp-140.sc.intel.com is the NTP server on the subnet.
Comment 5 Harald Hoyer 2004-10-05 05:33:28 EDT
yes, I know, but which kind of machine is this? a linux PC?
Comment 6 H.J. Lu 2004-10-05 11:55:59 EDT
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 12:06:56 EDT
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 09:05:53 EST
so bug or rfe?
Comment 9 H.J. Lu 2004-11-29 13:44:05 EST
It is a regression from RHEL 3.
Comment 10 Harald Hoyer 2004-11-30 05:39:03 EST
Ok, posted:
http://bugzilla.ntp.org/show_bug.cgi?id=364
Comment 11 Jay Turner 2005-01-14 09:21:11 EST
Back in assigned, as we're no longer awaiting information.
Comment 12 Miroslav Lichvar 2010-03-19 05:54:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.