Casper.Dik at Sun.COM wrote: >> 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.
You can still use "TZ=localtime" and make a "localtime" link under the zoneinfo dir, but I agree that reading "localtime" by default would be nice to have for those people who would like to change the timezone dynamically. >>> 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. Yes. But libc.so.1 would be an extreme example. We thought that such file/memory page needs to be protected in certain degree to avoid catastrophic result. If that's a regular file someone(has root privilege) may carelessly truncate it or unlink and re-create it. We just wanted to minimize those risks. If we shouldn't worry about those, I'll revise the spec to use a regular file. -Nakano
