Changing System Clock

[Regina Mitchell]

Model - 9000/800/SD32000
OS - 11i

The system clock on is not accurate. For example, the system clock is off by 2 hours and 6 minutes (Two hours behind). This server currently is not pointing to a ntp server.
I would like to point the server network time server. I will lookup instructions to do so. I'm just concerned of the following:

1) What are the risk of changing the clock with that much varience to bring it current?

2) Will the server have to be shutdown as well as the database and applications? Will Single user mode be best to implement NTP?

Thank You in advace for all replies.

[Pete Randall]

Since it is two hours behind and you will be setting the clock forward, there is very little risk. The main risk when changing time comes from messing up the DB re-do logs when setting the time backwards.


Pete

[Keith Johnson]

1) Moving the system clock forward is low-risk; even a two hour difference.

2) You don't need to shutdown anything or boot to implement NTP. Simply make the appropriate entries in the /etc/ntp.conf file. (man xntpd for details)

[Regina Mitchell]

Actually the server is pointed to ntp servers but the time is still off. I plan to change the system clock? This server is part of a two node Service Guard cluster. The other node has the correct time.

Any advice on how to proceed or what to check prior to me changing the system clock?

[James R. Ferguson · Accepted solution]

Hi:

When you setup NTP ('xntpd') you need to set your server's time to a very nearly correct value to allow 'xntpd' to synchronize your server's time. NTP will abandon all attempts at time synchronization if its time source and its server differ by more than about 1000 seconds.

I would suggest that you configure NTP to set the server time to that of its time source(s) during bootup (by configuring the NTPDATE_SERVER variable in '/etc/rc.config.d/netdaemons') and thereafter let NTP run continuously.

Setting your local time forward isn't a problem. Setting time backwards can cause great problems with database recovery, transaction synchronization, logs and cron tasks. Should you need to step the time backwards, having configured the NTPDATE_SERVER variable means that the time the change is made during startup before the time-sensitive things (databases) are started.

Hence, if you need to move time backwards, I would arrange a point where you can simply reboot with the above configuration in place. If your local time is behind true time, you can simply step (with 'date mmddhhmm') the time to very near what is correct and thereafter let NTP synchronize your clock.

Setting up NTP is simple and it can be done during normal production. There is an excellent guide in the "Installing and Administering Internet Services" manual in chapter-7.

Your best source of an external time source is three (3) servers from the NTP "pool" of public sources:

http://ntp.isc.org/bin/view/Servers/NTPPoolServers

Regards!

...JRF...

[Bill Hassell]

Very important: Make sure your system clock is REALLY off by 2 hours. When you login and type the date command, you are seeing a translation of the system's internal time (which is UTC or GMT), so verify what your system clock reads with:

date -u

Then find the current UTC time using the web page:

http://tycho.usno.navy.mil/cgi-bin/anim

If your system clock is within is couple of minutes of the UTC time, then NTP will work OK -- but first verify that all your NTP servers are available:

ntpq -p

If this reports an error or all the servers have a REACH=0 or DISP=16000, then your network is blocking NTP. Contact your network admin to unblock portr 123.

Now if UTC is correct and your login time is wrong, the value for $TZ is incorrect. HP-UX can use *ANY* timezone in the world -- all at the same time! The TZ value points to an entry in /usr/lib/tztab which then tells the library calls how to format the time for the local timezone.

Now if date -u shows the time is slow by 2 hours, you can move the time forward safely. However, to avoid issues with the TZ value, set the date with date -u and use the current GMT value. Then use date with no options to see the local date as translated by TZ.

[Regina Mitchell]

When I do ntpq -p I get the following:

/>/usr/sbin/ntpq -p
/usr/sbin/ntpq: read: Can't assign requested address

Maybe it is blocked by the firewall. So I guess I'll use the date -u command as suggested until I can get the firewall port opened.

Can I do this without shutting down the databases and application?

[Bill Hassell]

> /usr/sbin/ntpq -p
> /usr/sbin/ntpq: read: Can't assign requested address

Nope, this is not what you would see if it were blocked. This is an internal error and generally means that the xntpd daemon is not running. This probably has been the case for a long time and may have been caused by some root administrator logging in with the wrong TZ value, seeing the time was off and changed it. The xntpd daemon sees the massively wrong time and refuses to fix it because NTP is a very conservative program. These errors have been logged in /var/adm/syslog/syslog.log for a long time. Every administrator needs to understand that on a production machine, especially with databases running, changing the time can have serious consequences.

DO NOT use the start/stop script for xntpd as it will force the time to jump to the correct value. You will make the needed adjustment manually when it is safe.

> Can I do this without shutting down the databases and application?

Only if you have to move the time forward. Moving it backwards can cause the database to detect future timestamps or worse, duplicate timestamps which may possibly corrupt the database. Note that NTP can correct the time (slowly) up to about 10 minutes. It will do so without gaining or losing any time ticks.

So if date -u is within a few minutes of UTC time, manually start xntpd. It will immediately move to daemon status and you'll get your prompt back. If all is well, you can use:

ntpq -p

and it should show all your NTP sources. If not, look at the end of syslog:

tail -20 /var/adm/syslog/syslog.log

You should see xntpd messages. If there are errors, you'll need to post them here.

[Regina Mitchell]

Thanks to all for the replies and I will assign points once I resolve this per your recommendations.

Bill I will use your suggestion and reply with I have done.

[Regina Mitchell]

Thanks to everyone. Bill you are correct The error I get is because the variance is too great for NTP to try to sync. There is an error in syslog that say the time needs to be set manually. I plan to change the time with set_parms date_time. Then I will stop and restart NTP. Thanks again to eveyone. I have reviewd all the links as well.

[Regina Mitchell]

I have found all of the responses very useful and helpful in resolving my issue.