time problem

[John Kittel]

HP-UX 11.11 , rp7410


After a recent outage, when the system was restarted, the NTP daemon refused to adjust the clock because the time error was too large. This was not noticed right away. Time is 3 hours behind. The system is running Oracle.

What is the correct way to get the time set ahead 3 hours? Would Oracle, or anything else, likely care if it was bumped in a single increment?

- John

[Jeff_Traigle · Accepted solution]

Typically, jumps ahead are not a problem. It would greatly depend on the application using the database, however.

In /etc/rc.config.d/netdaemons, you should assign the NTP server(s) to the NTPDATE_SERVERS variable. This will allow ntpdate to run at system boot time and you'll avoid the problem.

[Patrick Wallek]

The thing I would *TRY* to do:

1) Shutdown everything
2) Reboot and come up in single user mode
3) Reset time to correct time
4) bring machine the rest of the way up to multi-user mode
5) Verify time is correct and that NTP is functioning correctly.

I would not try to do this while the system is in production and Oracle is up. It is entirely possible that Oracle could get confused if the time were to leap ahead 3 hours suddently.

Another possibility is the use of the 'date -a' command. The '-a' option will slowly adjust the time by whatever number of seconds you specify.

So if you were to do: date -a 10800

The time would slowly be adjusted forward by 10,800 seconds (3 hours). 'man date' for more info.

I would use this with care as well. You might get away with that on a live system. It would be better if you could test on a non-production system first.

[John Kittel]

NTP is configured. As I said, it noticed that the time error was too large, so it refused to adjust the clock and exited.

- John

[James R. Ferguson]

Hi John:

The 'xntpd' daemon will terminate if its view of its time source differs from it by about 1000 seconds.

I use Jeff's approach. That is, declaring a value for 'NTPDATE_SERVER' (i.e. your time source) in '/etc/rc.config.d/netdaemons' causes an immediate adjustment during startup before things like time-sensitive databases are launched. This eliminates the problem you currently have, although stepping the clock foward is seldom a problem. Moving time backwards can cause potential recovery issues and is best handled as Patrick suggests by shutdowns and reboots.

Since time for you is behind what it should be, you can set it ahead to very near the correct value and manually initiate 'xntpd' afterwards:

# /sbin/init.d/xntpd start

Regards!

...JRF...

[John Kittel]

Thanks everyone.

I didn't understand Jeff's advice at first, so thank you for the clarification James.

- John

[Bill Hassell]

I would be concermed that this will happen again. Is there anything in rc.log that shows why the xntpd script did not correctly set the time at reboot. As mentioned, the line in netdaemons:

export NTPDATE_SERVER=myntp.someplace.com

must work correctly as this is the known-to-work NTP server that will set the time on reboot. CVheck that it is functioning with:

ntpq -p myntp.someplace.com

If this server is not reachable, pick another server. You may want to add a reboot check script that scans rc.log looking for reboot errors and take the appropriate action(s), usually notifying all the sysadmins as to the problems.

[Leon Allen]

Jumping the time forward 3 hours is pretty safe with oracle for two reasons:

1) It can be viewed virtually as a 3 hours period where 'nothing' happens.

2) Oracle doesn't use 'time' as the basis for 'sequencing/ordering' things. It uses SCN's - System Change Numbers - sequential, time independent markers.

(BUT running time backwards requires a bit more thought and perhaps a different approach.)

[RAC_1]

You can just set the time with ntpdate "ref_host" and then check with ntpq -p and then start xntpd.

ntpdate will set time to that of ref system.

[John Kittel]

I followed advice to add NTPDATE_SERVER in /etc/rc.config.d/netdaemons.

Thanks everyone.