topic Re: ntp challenges in Operating System - HP-UX

ntp challenges

Shawn Miller_2 — Wed, 30 Oct 2002 15:07:44 GMT

I am syncing up my hp unix server to an nt server. The nt server has access to the internet and is sync up there. I used SAM to set this up and in the syslog it states that it is syncing to the nt server. However, the unix servers are 10 minutes behind the real time and I have not seen any changes over the last 10 hours to the unix time. What else do I need to do.

Re: ntp challenges

Christian Gebhardt — Wed, 30 Oct 2002 15:09:14 GMT

Hi
look at "man xntpd"

...
xntpd exits if it detects that the system clock is off by 1000 seconds or more.
...

1000 seconds are more than 10 minutes but are you running in this problem ??

Chris

Re: ntp challenges

Robert-Jan Goossens — Wed, 30 Oct 2002 15:23:03 GMT

Hi,

Has your NT server been setup as XNTP server ?

check on unix.

/sbin/init.d/xntpd stop

ntpdate

tail -20 /var/adm/messages

Robert-Jan.

Re: ntp challenges

James R. Ferguson — Wed, 30 Oct 2002 15:29:12 GMT

Hi:

If 'ntpd' sees a time difference in excess of 1000 seconds synchronization will cease.

You will need to step your time manually
If you are running 11.x, you can use 'date -a [-]sss[.fff]' to slew the server's clock backwards or forwards. When the clock is close to the correct time, restart your 'ntpd' services.

Otherwise, stop any time-critical processes (particularly databases where transaction timestamps are critical to integrity) and step your clock. If the adjustment is backwards, it may be simplest to reboot. Otherwise, restart 'ntpd' after the clock adjustment.

Regards!

...JRF...

Re: ntp challenges

John Dvorchak — Wed, 30 Oct 2002 18:02:17 GMT

You can also shut off xntpd with:

/sbin/init.d/xntpd stop

Then manually sync the time to the nt box:

ntpdate 123.123.123.2 (the nt's ipaddress)

Then restart xntpd:

/sbin/init.d/xntpd start

Verify that it is working:

tail /var/adm/syslog/syslog.log

Re: ntp challenges

Shawn Miller_2 — Wed, 30 Oct 2002 19:29:57 GMT

Thanks for the additional info. Again my server is 10 mintues off so I am under the 1000 seconds. How does ntpdate update the clock if you need to go back in time. Does it slow the server clock down until it catches up or does it make jumbs back. I have oracle running on these servers and jumping the date back is probably a bad idea.

Re: ntp challenges

Jeff Schussele — Wed, 30 Oct 2002 19:36:58 GMT

Hi Shawn,

I thought my math was failing me as well there for a second....

You have the two options already:
1) Slew the time with date -a as JRF suggests. That's what I'd prefer.
OR
2) Stop xntpd & jump it forward with ntpdate as John has stated.

Either way you'll be fine as your moving forward - not backward. You'll just see more "gaps" in logs via method 2 but it should cause no harm.

Rgds,
Jeff

Re: ntp challenges

John Dvorchak — Wed, 30 Oct 2002 19:37:24 GMT

Ok that's the bad news, ntpdate jumps the time instantly. You original question states "the unix servers are 10 minutes behind the real time " so it looks to me like it would be ok to jump the time forward.

concerning that 10 hours and no change could you stop and start xntpd on the HPUX box and tail the /var/adm/syslog/syslog.log file so we can see what is going on with your xntpd. Also ps -ef |grep xntpd would be nice after you restart it.

Re: ntp challenges

Bill Hassell — Wed, 30 Oct 2002 19:46:58 GMT

Slewing time (the date command or ntpdate -B) is done by slowing or speeding up the clock just slightly, such that every second in the day will occur. This keeps curernt production jobs from getting confused and cronjobs from not running.

The key is that a reboot will set the time directly from the NT server early in the reboot process. But before you do anything else, make sure the NT server is actually working! Use the command:

ntpq -p 123.456.789.0

or whatever the NT server's IP or hostname might be. If that fails, xntpd has been logging all sort of errors in your syslog about a dead server. Here's what a good server might look like:

ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
*gpstime.srv.gxp gpinet2.gxpac.c 3 u 1 64 377 2.01 0.107 0.08
+gpstime2.srv.ga gpinet2.gxpac.c 3 u 6 64 377 1.83 6.195 0.58
+gpstime3.srv.ga gpinet2.gxpac.c 3 u 47 64 377 1.94 13.071 0.31

The columns won't match vertically because of the proportional font used in the ITRC Forums, but the key is: reach should be 377 meaning that the server is reachable and reasonable as a time server. If instead you get host unreachable or connection refused, that is the real problem. Again, all of these errors are logged in /var/adm/syslog/syslog.log--just grep for xntp.