Effect of Correcting Time Downward on Running OS

[Alzhy]

I know this is really a common sense thingy and has all "it depends" marks all over but just want to ask anyway.

We have a gang of servers that inadvertently dropped off their NTP servers (whis IP/DNS changed). All are now on average ~20 minutes ahead of actual time.

If I adjust it "online" -- with DBs, mid-tier apps and front-end apps (web tier) running -- will there be serious repercussions? Maybe dangeorus with financial systems -- right?

[Ismail Azad · Accepted solution]

Hi,


This will create a problem for :-

1) Authentication mechanisms on NFS
2) Incremental backups

{what i can think of off the top of my head}

If you can risk these criteria go ahead bringing time downward, however, this can cause disaster to "time sensitive" applications.

Regards
Ismail Azad

[Alzhy]

Ysmael,

Thanks... will check with client. I simply missed the apt terminlogy "time-sensitive"...

[Pete Randall]

And database logs can get really messed up which can cause huge problems if you have to roll back a transaction or have to recover the DB.


Pete

[Duncan Edmonstone]

But you shouldn't have to change the time all in one go...

both date(1) and ntpdate(1m) offer capabilities to "slew" the clock adjustment by shortening/lengthening a second for however long it takes to get the clock back in sync (see the adjtime(2) system call)

Its all in the man pages...

HTH

Duncan

[Bill Hassell]

Whiule NTP can slew the time between seconds, it can only correct for about 12 minutes of mismatch. For a 20 minute correction, the clock cannot be changed enough to complete the task in 24 hours. NTP guarantees that there will always be 86400 seconds per day.

The best way to fix this is to first verify that NTP is now communicating with valid servers (hint ntpq -p and /etc/ntp.conf). If not, fix that first. Then reboot the servers. HP-UX will automatically 'jump' the time and date to the value returned by the NTP server in /etc/rc.config.d/netdaemons. The alternative is to shutdown all applications on one server, then set the date manually and restart the applications. Be careful that $TZ matches your current timezone. The data command will translate what you type into the correct GMT/UTC offset. If $TZ is wrong, then the new time will be wrong.

[Ismail Azad]

Hi,

Typical NTP behaviour suggests that a drift of around 1000 seconds would cause the xntpd daemon to die and yes, 20 minutes is more than that and as bill said a reboot would do this for you because ntpdate -b would jump the time the way you would want it to.

Regards
Ismail Azad