BST Daylight Time Savings in SUN Cluster 2,.2

[art15t]

Hi,

We'll shortly be coming round to that time of the year here (in the UK) where our machines will auto roll back one hour at 2.am on 31/10/04, but we have mission critical updates taking place on our E10K domains here (which take their times from our SSP's) and we need to make sure that nothing goes wrong, so ...

What's the best approach on this? I was thinking that it would be safer if prior to 2am we switched off xntpd on all our cluster nodes and let our batches run to completion. once done we would shutdown all DB's, restart the xntpd's on the cluster nodes (making sure that the time resyncs) before finally restarting out db's (and other apps)

As usual the business isn't able to give us time for a test run and they won't delay the batch, so we have to get this right.

The other thing is will our cluster panic if NTP isn't running?

Any ideas welcome!!

ART

 

[daFranze]

afaik NTP sends time info in Universal Time Zone UTC (this is more or less Greenwich Mean Time), your (UNIX) host-xntpd is converting this info into seconds since 1.1.1970 0:00 UTM (UNIX-time) and compares the delta to the time on your local machine (systemtime). If needed ntpd will adjust time on your host. Delta must not be larger than configured. When switching from UK-Summertime back to UK-Wintertime UTC does not change, in my eyes there is no need to worry.
To be 100% sure call Sun Service...

a very large FAQ about NTP:

http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-a-faq.htm

Best Regards, Franz
--
Solaris System Manager from Munich, Germany
I used to work for Sun Microsystems Support (EMEA) for 5 years

 

[Mike042]

Hi art15t,

I don't think your approach will work. Last year on a Solaris 8 system without NTP, the system time-of-day clock switched itself back from 02:00 BST to 01:00 GMT on the last Sunday in October. What we did was to shutdown our databases between 00:00 (midnight) and 01:00 and then restart them at 03:00. Perhaps not a very practical solution for you. Our Oracle DBAs did receive assurances from Oracle that these clock changes (back 1 hour in Oct and forward 1 hour in Mar) should not affect a database unless you attempt a roll-back to a point in time between 01:00 and 03:00.

However I did discover an alarming side-effect for cron jobs in that any scheduled to run between 01:00 and 02:00 on "Clock-change Sunday" in October will run twice. Please feel free to test this out yourself with the following cronjob entry:

00,10,20,30,40,50 0-3 * * 0 date >> /path/to/clock_change.log

I hope this helps.

Mike

 

[art15t]

Thanks for your input folks. I let the situation ride and all went well. The only problem (as Mike rightly pointed out) was that cron would run those entries twice but seeing as we run a separate scheduler for batch and the only thing we use cron for is system monitoring scripts, we could live with these entries running twice anyhow!

My real concern was due to upgrades we were performing and the fact that our clustered E10K domain might panic because the hosts get their time from the SSP's