Operating System - Tru64 Unix
1748142 Members
3597 Online
108758 Solutions
New Discussion юеВ

Re: Clock change

 
Amanda Deer
Frequent Advisor

Re: Clock change

Europe/London Tue Apr 4 14:25:01 2006 BST
Europe/London Sun Mar 26 00:59:59 2006 GMT = Sun Mar 26 00:59:59 2006 GMT isdst=0 gmtoff=0
Europe/London Sun Mar 26 01:00:00 2006 GMT = Sun Mar 26 02:00:00 2006 BST isdst=1 gmtoff=3600
Europe/London Sun Oct 29 00:59:59 2006 GMT = Sun Oct 29 01:59:59 2006 BST isdst=1 gmtoff=3600
Europe/London Sun Oct 29 01:00:00 2006 GMT = Sun Oct 29 01:00:00 2006 GMT isdst=0 gmtoff=0
Martin Moore
HPE Pro

Re: Clock change

That's mystifying. Based on your zdump output, the system should have changed to BST on the 26th. I don't think NTP is an issue; NTP uses universal time (GMT) and it's up to the client system to translate that into its local timezone.

Since the system continued to say GMT rather than BST, it's clear that it didn't switch when it was supposed to. If you haven't manipulated the date or the timezone files recently, I'm at a loss to explain this.

If you have the freedom to do so, it would be interesting to set the time back to 26 Mar 00:55 (5 minutes before the scheduled change) and let the time advance normally to see if it changes properly.

Martin
I work for HPE
A quick resolution to technical issues for your HPE products is just a click away HPE Support Center
See Self Help Post for more details

Accept or Kudo

Amanda Deer
Frequent Advisor

Re: Clock change

I might be able to try this on my test system tomorrow. For now though I need to get the time corrected on my production system. Should I just use the date command to reset it?
Howard Anderson_2
Frequent Advisor

Re: Clock change

NTP could have been an issue, if a mis-configured reference clock was being used.
Mine can be configured to switch to BST (or other daylight saving time) and output this in the NTP stream.
Hence my questions about NTP config. However you say the NTP server is non-existant so that should not be a problem.
On TruCluster 1.6, I would have checked all cluster members had a consistent config for the localtime symlink. However I don't have experience of 5.1A clustering, if you have separate root filesystems on your cluster systems you ought to check this.
You should be able to use date, but I know you have to be carefull setting the clock back in time, as the system can get very confused.
Martin may be able to advise you better?

I have seen this clock jump issue before (about 3 years ago) but I cannot remember what the cause was, sorry.
Martin Moore
HPE Pro

Re: Clock change

Using the date command is the way to reset the time, but I would be EXTREMELY leery of setting the time backwards on a production system. If you have a database application running, you could wind up with inconsistent timestamps, for example.

The safest way to reset the time would be during a period when you can have the production services down for an hour:

1. Shut down production services.
2. Wait at least one hour.
3. Set the time back. You may even want to drop to single-user mode to do this.
4. Restart services.

To answer Howard's question, the timezone files on a V5 cluster are in cluster_root, i.e., not member-specific. But this is worth a check. Please ensure that /etc/zoneinfo and none of the files under it are CDSL's. Something like:

ls -lR /etc/zoneinfo | grep '{'

Martin
I work for HPE
A quick resolution to technical issues for your HPE products is just a click away HPE Support Center
See Self Help Post for more details

Accept or Kudo

Amanda Deer
Frequent Advisor

Re: Clock change

Thanks - I'm going to stop all applications (there are no databases) wait for an hour and set the time back. will date -n do it?
Martin Moore
HPE Pro

Re: Clock change

Yes, but you'll need to do it on each cluster member.
I work for HPE
A quick resolution to technical issues for your HPE products is just a click away HPE Support Center
See Self Help Post for more details

Accept or Kudo