>Casper.Dik at Sun.COM wrote: >> Now that we have this large mechanism to update the timezone information, >> I'm missing a number of things: >> >> it appears not to be possible to change the timezone dynamically; >> there are customers who want this. In the initial implementation >> of Olson's code uses a link called "localtime" and with a broadcast >> mechanism we could have this function pretty much for free; >> should this not be added to this project? > >It is possible if timezone is not supplied by TZ env variable. >localtime() will reload /etc/default/init as well. If timezone is >supplied by TZ env variable, "localtime" approach is needed. >Currently "localtime" isn't read by default, but it is out of >scope of this project.
Except that localtime *may* read /etc/default/init but by default it will NOT because all processes have $TZ set from the boot time /etc/default/init. You can get that in two ways: use "localtime" or not set $TZ for all processes; as setting $TZ is a optimization. So perhaps that's a better solution: do not set $TZ in the environment. >Using Olson's code can change the timezone dynamically, but only >for processes which were restarted or started after the file is >changed. Active processes which have loaded "localtime" never >reloads the file. > >> how is the semaphore checked and why is a mmap file in, say, >> /var/run not good for this purpose? > >If the file can be truncated, it could potentially send SIGSEGV to >all active processes that calls ctime(3C). By root, right? Root can also truncate /lib/libc.so.1 so that doesn't fly. Casper
