Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We are trying to configure NTP with Chicago time but it is showing the st 16u. Also cant see any reference (*) to amy remote server.

>>ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

 nist1-chi.ustim .INIT.          16 u    - 1024    0    0.000    0.000   0.000    
 zeus.yocum.org  .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 conquest.kjsl.c .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 stratum-2-core- .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 vimo.dorui.net  .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Configuration deatails ate as follows: [cat /etc/ntp.conf]

 # Permit time synchronization with our time source, but do not
 # permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery

 # Permit all access over the loopback interface.  This could
 # be tightened as well, but to do so would effect some of
 # the administrative functions.
restrict 127.0.0.1 

 # Hosts on local network are less restricted.
 #restrict 192.168.16.0 mask 255.255.255.0 nomodify notrap

 # Use public servers from the pool.ntp.org project.
 # Please consider joining the pool (http://www.pool.ntp.org/join.html).
 #server 0.rhel.pool.ntp.org
 #server 1.rhel.pool.ntp.org
 #server 2.rhel.pool.ntp.org

server nist1-chi.ustiming.org
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org

 #broadcast 192.168.1.255 key 42         # broadcast server
 #broadcastclient                        # broadcast client
 #broadcast 224.0.1.1 key 42             # multicast server
 #multicastclient 224.0.1.1              # multicast client
 #manycastserver 239.255.254.254         # manycast server
 #manycastclient 239.255.254.254 key 42  # manycast client

 # Undisciplined Local Clock. This is a fake driver intended for backup
 # and when no outside source of synchronized time is available. 
 #server 127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

 # Drift file.  Put this in a directory which the daemon can write to.
 # No symbolic links allowed, either, since the daemon updates the file
 # by creating a temporary in the same directory and then rename()'ing
 # it to the file.
driftfile /var/lib/ntp/drift

 # Key file containing the keys and key identifiers used when operating
 # with symmetric key cryptography. 
keys /etc/ntp/keys

 # Specify the key identifiers which are trusted.
 #trustedkey 4 8 42

 # Specify the key identifier to use with the ntpdc utility.
 #requestkey 8

 # Specify the key identifier to use with the ntpq utility.
 #controlkey 8
share|improve this question

3 Answers 3

Looks like you cannot reach any NTP server:

The "reach" field is actually a register (shown in octal number format) that gets shifted one bit to the left before every poll. In case the polling is successful, the register ir OR'ed with 001 (octal).

A "healthy" ntp should have a "reach"ability of 377 like the one below:

ntpq> pee
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l   52   64  377    0.000    0.000   0.001
*myLocalNTP      .PPS.            1 u  169  256  377    0.484   89.023  32.295

Probably this is a firewall / SELinux issue. Please check that you can reach the remote ntpserver ( ntpdate servername should do the trick). If this fails, traceroute -U -p 123 servername may help you spot which node is dropping your ntp packets.

share|improve this answer
1  
I have always been wondering about that reach column. I have noticed that it goes between 0 and 377 (bad to good) but never understood the actual meaning. Finally I understand! An octal bitmap. Thank You! –  snap Sep 12 '11 at 13:56
    
A "healthy" ntpd configuration should not have the LOCAL clock. The local clock is a relic of yester year. –  dfc Nov 5 '12 at 2:26
    
Your "local" ntp source has a delay of0.484? How do you define local? Same solar system? –  dfc Apr 8 at 3:07

Note that there's no "Chicago Time" per se. Everything coordinates with UTC, with time zones set locally (e.g., CDT = UTC-5).

What happens when you stop the ntpd daemon, and run "ntpdate 0.pool.ntp.org"? Do you get a large offset? I'm wondering if you're trying to force Chicago time on ntpd but your time difference is too large for it to coordinate (i.e., your computer thinks Chicago Time is actually UTC, so the offset is 18000 seconds).

share|improve this answer

Take a look at this post and the whole thread. Somebody had a similar problem to yours. Also in the thread there are shown commands which will help you debug the problem.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.