timezone configuration change

[Kenan Erdey]

Hi,

In turkey timezone changes will be done with one day latency. ( in spite of March 27, it will be on March 28.

changing tztab will be ok. but if you look at the output of fuser /usr/lib/tztab, a lot of processes like oracle,cimserver and other system processes opened it.

will it be ok, if i change inode number of tztab after editing ? or should i have to reboot ?

[James R. Ferguson · Accepted solution]

Hi:

You will need to restart any processes that was already running at the time of the alteration. This would include the 'cron' daemon, oracle processes, etc. A shutdown and reboot might be the quickest, most sweeping way.

That said, you have another issue to consider. If you leave the modified 'tztab' in place, the next time you attempt to apply a standard patch for ' tztab' that updates timezone information, regardless of whether or not it impacts the stanza you modified, the update will _not_ fully complete. That is, 'swinstall' will detect that you modified 'tztab' and leave the new, standard version in 'the /usr/new' directory. Caveat emptor.

Regards!

...JRF...

[Kenan Erdey]

it's interesting that tztab is a text file, you can edit and after changing values system time shows the correct value corresponding to the changes. but i tested cron, it failed. job run in the wrong time.

[Hakki Aydin Ucar]

Apart from your exact request I want to add, another way to do it, to use an automated ntp server in Turkiye if you can afford it, so no need to do any other thing, system will be updated by ntp server.
This is what I did in every year. just check the ntp server is up and running ..

[Kenan Erdey]

Hi,

ntp server just gives you utp time. if you change timezone in ntp server, clients do not change time. if you change time manually in ntp server, in the next check in clients, they will see 1 hour difference, so they aborts them without updating.

[Patrick Wallek]

>>but i tested cron, it failed. job run in the wrong time.

Stop and restart cron, and then try rerunning your job.

# /sbin/init.d/cron stop
# /sbin/init.d/cron start

Then try scheduling a job to run.

[Kenan Erdey]

i'll possible to run in the correct time. but how about the other system processes ? which one of them will i restart ?

[Kenan Erdey]

and there are thousands of server..

[Patrick Wallek]

That is why it can be easier to just reboot if there is a tztab change (see James' response above).

[Dennis Handly]

What HP-UX version are you using?

There is code is libc to detect that the mmapped file has changed but I'm not sure how robust the detection is.

>In turkey timezone changes will be done with one day latency.

How long has this change been proposed, years? Have you asked HP to provide a patch for this?

>and there are thousands of server.

Right and syslog runs on local time.

[Kenan Erdey]

Hi again,

that said changing inode numbers will affect caching tztab file. i tested but nothing changed on cron, etc..

it'll be just for 2011.

[Hakki Aydin Ucar]

>Kenan: ..if you change time manually in ntp server, in the next check in clients, they will see 1 hour difference, so they aborts them without updating.

OK, on my understanding you (and others) know something that I don t know OR I never used ..

I have 30 servers of HP unix and linux in my customer network, and I do not need to change time zone just ntp server adjust the clock (it is out of network,mean external) ,when it updates all servers updated , all databases we use (not Oracle by the way..) without problem, accept the change even though clocks put 1 hrs ahead ,they will updated.
when I check the server I can see the status, with the command "ntpq -p"

regards.
Hakki

[Hakki Aydin Ucar]

Hi again,

Ok, probably two different method direct adjustment with passive TZ (my setup) and auto TZ based adjustment available,
I guess, they are incompatible
for example in my example TZ is disabled somehow:
# echo $TZ
EET-2EETDST
so we are ntp based clock adjustment ,but you need to update tztab
http://h30499.www3.hp.com/t5/System-Administration/Where-does-usr-lib-tztab-log-the-time-of-change/m-p/5104607#M444812

if you use HP-UX 11iv1 server need to be sure patch applied before changed :
PHCO_39172

But remember the fact that time doesn't change actually,but changes for how it is displayed :)

[Kenan Erdey]

Hi Hakkı,

we have already ntp server oriented clients. and they all adjusting the time according to the time passed from 1970. ntp server and clients are adjusting their time to the timezone value. we will change this value so that it will change on monday instead of sunday. that was the problem.thanks.

[Hakki Aydin Ucar]

I see, you are talking to ntp server TZ modification ; it is real headache, so you need to do something like that as a workaround:

-Stop all clients ntp daemon on Saturday :
# /sbin/init.d/xntpd stop
-then solve the problem on ntp servers on Sunday after midnight ? (maybe adjust manually?)
-then start ntp clients:
# /sbin/init.d/xntpd start

Actually ,the second step to be solved somehow .. I know it is not easy way but just a workaround.

[James R. Ferguson]

Hi:

> Hakki : I see, you are talking to ntp server TZ modification

That's an oxymoron. NTP works with, and only with, UTC (GMT) in the number of seconds since the Unix Epoch (January 1, 1970 at 00:00:00 UTC).

What you (or your server) perceives as the correct time is based on a +- offset from UTC. This offset is what is known as "localtime". The rules for the amount of offset from UTC to apply during any given period of a year is defined in HP-UX in '/usr/lib/TZTAB'. This information if read and cached by the libC libraries is why I advised Kenan to restart long-running processes if the 'tztab' is modified. Re-read what I originally wrote.

Regards!

...JRF...

[Kenan Erdey]

safetest way is reboot.