Time Synchronisation

[Donald Thaler]

trying to sync a client to a master both servers are internal.
master (10.2.2.28)
etc/ntp.conf
server 127.127.1.1
etc/rc.config.d/netdaemons
xtnpd=1
client..etc/ntp.conf
server artemis version 3
*(artemis is hostname of master)
etc/rc.config.d/netdaemons
xtnpd=1
ntpdate_server=10.2.2.28

stopped and started xtnpd on both servers.
client is 4 minutes faster than master and it doesn't seem to be slowing down... did i miss a step somewhere ??

[TTr]

Adding a drift file in /etc/ntp.conf is a ggod idea. I don't know if xntpd uses a default if you don't specify it.

Check the syslog for any xntp messages.

In etc/rc.config.d/netdaemons add debugging option and if you want a separate log file option as in XNTPD_ARGS="-d -l /var/adm/syslog/xntpd.log". Then restart the daemon and check the log.

[Heironimus]

How long have you waited for it to correct? Does ntpq -p on the client look good?

[Donald Thaler]

the ntpq -p on the client is not returning the full name of the master, instead of artemis.lccc.edu, it's returning artemis.lccc.ed and the ref id is 0.0.0

[Heironimus]

The ntpq output is truncated to fit the field width, so don't worry about a missing "u" at the end of the server name. The refid is "0.0.0.0" because the server isn't configured with an upstream time provider and is also not a cause for concern. Is there a character (like a "*" or "+") in the first column next to the server name?

The time that has passed since you started ntpd on the client is important because a 4-minute difference could take days to correct.

[Donald Thaler]

no special character in front of server name.. guess i'll wait till monday to see the time on the server is changing

[Donald Thaler]

when i do ntpq -p on the master i get this ntpq: read: Can't assign requested address

[James R. Ferguson]

Hi Donald:

The "can't assign..." message from 'ntpq' means that XNTP has died or isn't running.

Verify that your server's time is actually correct in UTC units:

# date -u

...should match a real world clock. If not, 'Xntpd' will not syncrhonize since it uses UTC time. Your 'TZ" setting simply changes your perception of UTC to a localtime by adding or subtracting an approprate offset.

Regards!

...JRF...

[Emil Velez]

I configure it in sam that way the file is correctly configured.

[Bill Hassell · Accepted solution]

ntp is very easy to configure but impossible to make work if you cannot contact the ntp servers. Before you do anything, make sure xntp is not running:

UNIX95=1 ps -fC xntdp

That should return nothing which is correct. Otherwise, kill the xntpd process. Now test that your server can see the NTP server:

ntpq -p 10.2.2.28

You will see something like this:

# ntpqp -p 10.2.2.28
remote refid st t when poll reach delay offset disp
==============================================================================
192.147.38.60 0.0.0.0 16 - - 1024 0 0.00 0.000 16000.0
*ntp.pbx.org clock.nyc.he.ne 2 u 755 1024 377 13.18 18.193 9.28
+kyna.dalbaech.n time-A.timefreq 2 u 824 1024 377 59.59 -29.138 0.53

The first line indicates that server 10.2.2.28 cannot get any time info from 192.147.38.60. That is the remote server's problem, not yours. The next 2 lines show that the remote server can talk to these time servers. This is a normal display.

However, if you get errors from ntpq such as unreachable, can't assign address, timeout, etc, don't go any farther. Your server cannot talk NTP to 10.2.2.28. Until this is fixed, the rest of the steps will be ineffective.

Once you fix the communication problem, now you can configure ntp.conf. While there are dozens of options, leave all that out and make it as simple as possible:

# cat /etc/ntp.conf
10.2.2.28 # company serverserver
fudge 127.127.1.1 stratum 10 # localhost fallback
driftfile /etc/ntp.drift

And that's it. NOTE: 127.127.1.1 should always have stratum 10 listed. This address is a fallback for NTP to use itself for sync until the servers return. But it must be the last choice, hence stratum 10.