System clock fast, need to set it back

[Robert Milne]

Hi all HP-UXer's,

The wonderful system clock on our L1000 is running 7 minutes fast and I need to set it back for database correct transaction time stamping (local time). I would assume there should be no dramas with this, but just looking to see if there are any gotchas I need to be aware of, like time stamping in log files or whatever immediately after the time rollback.

My plan is to shut our Progress database down (of course !), shut the system down to single user mode, use the date function to set the clock back to the correct local time, wait the seven or so minutes for the actual time to pass the original system time where I rolled it back from; then reboot the system back to normal operation, and finally restart the Progress database again.

Is this reasonable ? Are there any traps for young players here, anything I should watch out for ?

Also I notice with interest in the man for date the following interesting entry:

-a [-]sss[.fff] Slowly adjust the time by sss.fff seconds (fff represents fractions of a second). This adjustment can be positive or negative. The system's clock will be sped up or slowed down until it has drifted by the number of seconds specified.

Does this mean I can apply some sort of factor to "slow" the clock until the real time "catches" up with the system time ? Maybe this is a better option to slow the clock up until system time is in sync with reality over a period of time, thereby avoiding a system shutdown and inconveniencing my users. I don't quite understand this function. Has anyone any experience with this option and/or examples as to how it works ? Any gotchas with this, particularly in relation to active databases which are time "sensitive" like Progress is ?

Any help/guidance appreciated from all you wizards.

All the best.

Rob.

[Tom Geudens]

Hi Rob,
Your procedure is fine, but just a little "add-on" :
- shut applications and databases
-- Measureware (for example) is very sensitive
-- best procedure is to go level 2 or 1
- set time (with date)
- shutdown
- interrupt the reboot and enter the PDC

*** you can wait those 7 minutes here ***

- check the time in the PDC and (if necessary) correct it there as well (is in GMT-time !!!)
- boot to level 1
- check time
- boot to level 3

Regards,
Tom

[Vincent Farrugia]

Hello,

I guess that's reasonable...

To keep your clock from running like Maurice Green, you can set it up as a time client with a local or foreign time server. You can find such servers on the internet, some having ultra-accurate time measuring technology.

Use SAM to set up this one, it's hassle-free.

HTH,
Vince

[Justo Exposito]

Hi Robert,

Another option is to configure NTP, if you have a router or other HP/UX box that has the correct time, you can configure the router as server and your L1000 as client, then you will have the same timestamps in both.

I Think that this is the better solution because you can configure it without stoping the box and the ntp software will do the synchronice between systems by seconds, perhaps in one hour you have the same timestamps.

You don't need to use the date command in order to change the time, ntp will do for you and the final result will be that you have the same date and time in both servers.

I do this and all the company boxes at this moment has the same time.

It's an easy way to do it and you can do it by sam.

Regards,

Justo.

[john korterman]

Hi,
just a thought: I do not know how long it took your system clock to gain seven minutes, but it could be interpreted as a symptom of unstable temperature in the server room. If that is the case, it could have other side-effects as well.

regards,

John K.

[John Palmer · Accepted solution]

Hi,

date -a works wonderfully well and means that you don't need to close any of your production systems. For 7 minutes fast, just use date -a -420

date - does indeed slow (or speed up) the clock until the time has been drifted by the required amount and uses the same mechanism as the NTP routines.

I've found that L class real time clocks vary, even when they're mounted in the same rack.

A technique that I use when NTP is not available is to note from observation how much the clock is out each day (I've found it to be pretty constant) and to run date -a in a regular cron job to adjust it.

Regards,
John

[Marc Dijkstra]

Hi there Rob,

I have a similar issue with 4 machines on a site, all of them are gaining time, although I have nothing to add of any use, do you mind if I hijack your thread and ask John Korterman if he could expound on the unstable temperature theory, as that is the case on this site. Is there any documentation to support this? as it would explain a lot.

Thanks for the slot!

MND

[Paul Thomson_2]

When setting back time. We use universal time as the mesaure, this being GMT.

After shutting down applications and databases.

use

date -u MMDDhhmm

Where MM = Month
DD = Day
hh = hour
mm = minute.

As we have servers around the world, the local timezone setting on server adjusts its time from GMT to calculate its local time.

[john korterman]

Hi Marc,

although the attached document deals with very specific hardware, I think it goes for all crystal oscillator driven time generators.

http://support4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000024128185

regards,

John K.

[Marc Dijkstra]

John,

Thanks a stack, exactly what I was after!

Rob, thanks for the space in yer thread, muchly appreciated.

MND