Clock change

[Amanda Deer]

Last weekend my Tru64 V5.1A systems didn't change to BST, they were still saying GMT. I had to adjust the time manually. This weekend though they have changed to BST and now are an hour fast. Any ideas why they changed on the wrong date?

[Ivan Ferreira]

Your zone file should be incorrect. Check with the zdump command:

zdump -v BST

You can modify your zone file and compile it with the right values, for detailed information see:

http://www.tldp.org/HOWTO/html_single/TimePrecision-HOWTO/#time

[Howard Anderson_2]

I am runnning systems on 5.1B and 4.0G with an external hardware clock providing them with NTP. They all switched on the correct weekend.

Do you have any external hardware providing time synchronisation ?

Are you using NTP to synchronsie from the Internet ?

Do you have a record of what location you told the OS to be in when you first configured the OS ?
This should also be in /etc/svid3_tz.
Mine is set to :London
Yours could also be :GB-Eire

Off the top of my head the critical one is the /etc/zoneinfo/localtime symlink.
This should point to London or GB-Eire in the /etc/zoneinfo directory.

[Amanda Deer]

We are using ntp, but the server we are using doesn't exist anymore. We have a cluster and I thought they were just synching between themselves. Which is the best way to tell where they are getting the time from?

[Michael Schulte zur Sur]

Hi,

you can do
cat /etc/ntp.conf

greetings,

Michael

[Ivan Ferreira]

Use ntpq -pn, the server with an '*' is your current time server.

[Amanda Deer]

remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 127.127.1.0 12 l 21 64 377 0.000 0.000 0.000
10.0.0.1 10.0.0.2 14 u 11 1024 377 0.440 -0.538 0.000


This is the output from ntpq -pn. The man page says 127.127.1.0 is a reference clock.

server 127.127.1.0 version 3
fudge 127.127.1.0 stratum 12
peer dcs1b-ics0 version 3

This is /etc/ntp.conf.

[Martin Moore]

Amanda,

What is the output of:

ls -l /etc/zoneinfo/localtime

[Amanda Deer]

lrwxrwxrwx 1 root system 15 Mar 31 2004 /etc/zoneinfo/localtime -> ./Europe/London

[Martin Moore]

OK, now please try:

zdump -v Europe/London | grep 2006

This will dump the times in 2006 that the London timezone is scheduled to change. On a V5.1A lab system here, I get the following:

Europe/London Tue Apr 4 12:57:56 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

(The first line is just the current time when I executed the command.)

This shows that the timezone should have changed at the correct time, 01:00 on March 26.

Let's see whether your zdump output is the same and go from there.

Martin

[Amanda Deer]

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]

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

[Amanda Deer]

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]

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]

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

[Amanda Deer]

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]

Yes, but you'll need to do it on each cluster member.