Hello all,
I just want to update the timezone file with new file to update the time, so the zone in /etc/TIMEZONE will be the same but the file it refers to will be changed, and the local time should be changed, can this take effect without rebooting Solaris 10?
Timezone is the representation of the system time.
If you change the timezone, applications might continue with the old representation, until they are restartet.
It is both unclear what file you plan to change and what need to be changed in it.
Can you provide more details about what is precisely expected?
Thanks for your Reply
/etc/TIMEZONE contains a timezone for example TZ=Africa/Tripoli as i know in solaris 10 to change this timezone i must restart the server so I will leave it as is and replace Tripoli file itself that contains new time (GMT+2 instead of GMT+3) so how to make this file take effect on the system without restarting the server?
No matter what files you change, the TZ setting of already running processes will not be affected. If you want to change the TZ setting in an application that is running, you need to restart that application.
If I understand properly, you do not want to change the timezone which will remain TZ=Africa/Tripoli but you want to replace the file storing the timezone definition, here /usr/share/lib/zoneinfo/Africa/Tripoli, by a file containing a different definition, presumably built with the zic command.
Assuming this is what you want to do, changes should affect the existing and future processes time representation immediately, i.e. without requiring a reboot. However, this is unsupported and there is a risk for a Solaris patch to overwrite your customized timezone.
Of course any new processes after the update will pick up the new timezone and that could mess up any logs that you write.
That depends on how the timestamps are formatted in the logs.
Usual log formats do not store the geographical timezone which is indeed unreliable but either GMT or some offset from GMT.
My concern would be that you might have the time being written as each process perceives it and there could be a mismatch, eg.
12:34:56 Event good
12:34:59 Event good
12:35:02 Event good
11:35:02 Event unexpected
12:35:03 Event good
If you have a busy and common application log, this could make quite a mess. An alternate worry might be if an application does it's own logging within a database. We have to switch of NTP for one of these when it kept complaining that the clock had moved back.
Not that these are necessarily a problem in your case, just something to consider. I must say I'm left to wonder why you would want to make such a change without a boot? Is it so hard to find a window to boot in?
Kind regards,
Robin
My previous answer is incorrect. I just looked at the localtime source code and noticed the time zone definitions are loaded only once and stored in a cache.
That means an altered timezone will only be taken into account by new processes but not by those already running.
I would then agree with rbatte1 and suggest the operation be followed by a reboot to make sure all processes, including init are in sync.