* do_tzset() prevents reusing the same name of a timezone file @ 2014-10-17 20:20 Королев Сергей 2014-10-19 2:20 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Королев Сергей @ 2014-10-17 20:20 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 424 bytes --] Hi, all. I have a question about do_tzset() function implementation (musl v1.1.5). The function has the following conditions to prevent timezone file remapping if (old_tz && !strcmp(s, old_tz)) return; which do not allow to use "TZ" environment variable pointing to the same file (e.g. /etc/localtime). But some distros replace this file directly or use it as a symlink. Is this limitation a bug or a feature? Thanks. [-- Attachment #2: Type: text/html, Size: 797 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: do_tzset() prevents reusing the same name of a timezone file 2014-10-17 20:20 do_tzset() prevents reusing the same name of a timezone file Королев Сергей @ 2014-10-19 2:20 ` Rich Felker 2014-10-19 7:26 ` Королев Сергей 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2014-10-19 2:20 UTC (permalink / raw) To: musl On Sat, Oct 18, 2014 at 12:20:05AM +0400, Королев Сергей wrote: > Hi, all. > > I have a question about do_tzset() function implementation (musl v1.1.5). > The function has the following conditions to prevent timezone file remapping > > if (old_tz && !strcmp(s, old_tz)) return; All this line does is prevent any reloading if the TZ variable has not changed since do_tzset() was last called. > which do not allow to use "TZ" environment variable pointing to the same > file (e.g. /etc/localtime). But some distros replace this file directly or > use it as a symlink. > > Is this limitation a bug or a feature? Can you clarify what problem you're actually experiencing? /etc/localtime is currently supported/used if TZ is unset or set to the empty string. Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: do_tzset() prevents reusing the same name of a timezone file 2014-10-19 2:20 ` Rich Felker @ 2014-10-19 7:26 ` Королев Сергей 2014-10-19 9:36 ` u-wsnj 0 siblings, 1 reply; 6+ messages in thread From: Королев Сергей @ 2014-10-19 7:26 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1270 bytes --] I have a symlink "/etc/localtime -> /var/TZ". Only "/var/TZ" contents modified for timezone changing but "TZ=/etc/localtime" variable (set in the init process) always stays the same. The constant TZ pointing to the symlink used to apply timezone settings for all active processes in the system on the fly. This needs for proper logging with the syslog. 2014-10-19 6:20 GMT+04:00 Rich Felker <dalias@libc.org>: > On Sat, Oct 18, 2014 at 12:20:05AM +0400, Королев Сергей wrote: > > Hi, all. > > > > I have a question about do_tzset() function implementation (musl v1.1.5). > > The function has the following conditions to prevent timezone file > remapping > > > > if (old_tz && !strcmp(s, old_tz)) return; > > All this line does is prevent any reloading if the TZ variable has not > changed since do_tzset() was last called. > > > which do not allow to use "TZ" environment variable pointing to the same > > file (e.g. /etc/localtime). But some distros replace this file directly > or > > use it as a symlink. > > > > Is this limitation a bug or a feature? > > Can you clarify what problem you're actually experiencing? > /etc/localtime is currently supported/used if TZ is unset or set to > the empty string. > > Rich > [-- Attachment #2: Type: text/html, Size: 1802 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: do_tzset() prevents reusing the same name of a timezone file 2014-10-19 7:26 ` Королев Сергей @ 2014-10-19 9:36 ` u-wsnj 2014-10-19 10:00 ` Timo Teras 0 siblings, 1 reply; 6+ messages in thread From: u-wsnj @ 2014-10-19 9:36 UTC (permalink / raw) To: musl On Sun, Oct 19, 2014 at 11:26:08AM +0400, Королев Сергей wrote: > The constant TZ pointing to the symlink used to apply timezone settings for > all active processes in the system on the fly. This needs for proper > logging with the syslog. I may misunderstand what you mean by "proper logging" but logging in local time when the time zone is expected to change does not look reliable to me. I would suggest telling the syslog daemon to work in UTC (by setting its TZ variable to a corresponding value). Then you always have consistent logs and do not have to analyze which time zone a certain logged event happened in. Regards, Rune ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: do_tzset() prevents reusing the same name of a timezone file 2014-10-19 9:36 ` u-wsnj @ 2014-10-19 10:00 ` Timo Teras 2014-10-19 17:33 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Timo Teras @ 2014-10-19 10:00 UTC (permalink / raw) To: u-wsnj; +Cc: musl On Sun, 19 Oct 2014 11:36:11 +0200 u-wsnj@aetey.se wrote: > On Sun, Oct 19, 2014 at 11:26:08AM +0400, Королев Сергей wrote: > > The constant TZ pointing to the symlink used to apply timezone > > settings for all active processes in the system on the fly. This > > needs for proper logging with the syslog. > > I may misunderstand what you mean by "proper logging" but logging > in local time when the time zone is expected to change does not look > reliable to me. > > I would suggest telling the syslog daemon to work in UTC (by setting > its TZ variable to a corresponding value). > Then you always have consistent logs and do not have to analyze > which time zone a certain logged event happened in. Perhaps logging is not best example here. But I think the original point is valid. If I use TZ=:localtime, and /etc/localtime symlink is updated to point to different file, or the tzdata is upgraded and the file is updated, long running processes should pick up the changes. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: do_tzset() prevents reusing the same name of a timezone file 2014-10-19 10:00 ` Timo Teras @ 2014-10-19 17:33 ` Rich Felker 0 siblings, 0 replies; 6+ messages in thread From: Rich Felker @ 2014-10-19 17:33 UTC (permalink / raw) To: musl On Sun, Oct 19, 2014 at 01:00:29PM +0300, Timo Teras wrote: > On Sun, 19 Oct 2014 11:36:11 +0200 > u-wsnj@aetey.se wrote: > > > On Sun, Oct 19, 2014 at 11:26:08AM +0400, Королев Сергей wrote: > > > The constant TZ pointing to the symlink used to apply timezone > > > settings for all active processes in the system on the fly. This > > > needs for proper logging with the syslog. > > > > I may misunderstand what you mean by "proper logging" but logging > > in local time when the time zone is expected to change does not look > > reliable to me. > > > > I would suggest telling the syslog daemon to work in UTC (by setting > > its TZ variable to a corresponding value). > > Then you always have consistent logs and do not have to analyze > > which time zone a certain logged event happened in. > > Perhaps logging is not best example here. But I think the original > point is valid. > > If I use TZ=:localtime, and /etc/localtime symlink is updated to point > to different file, or the tzdata is upgraded and the file is updated, > long running processes should pick up the changes. This behavior is intentional. Constantly polling the filesystem on every time operation is a major performance bottleneck (there have actually been glibc bug reports on this issue; I don't remember how they were resolved) and having things change out from under the application is also a big problem from a robustness standpoint. In a multithreaded program where the timezone changes asynchronously, there are fundamental, unfixable race conditions that affect things like strftime formatting with %Z (since there is no way to hold a lock across both the call to localtime and the call to strftime). So the implementation should not impose these on an application that is not expecting/willing to accept them (via changing TZ itself). Presently, applications that specifically do want to force re-loading of the timezone (and which are single-threaded or willing to accept the data races) can do so via temporarily setting TZ to something else, calling tzset, then resetting it. I don't know any other good way for applications to convey this intent. Really, this is no different than any other state the application inherits from the environment, like locale, executable search path, library path, etc. As long as these are treated as immutables, they're harmless. If they're modified internally by the program, they're harmful global state, but managable by many programs. But if you decided you wanted to be able to poke at them asynchronously from outside the program, you've enterred the realm of utter insanity. Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-19 17:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-17 20:20 do_tzset() prevents reusing the same name of a timezone file Королев Сергей 2014-10-19 2:20 ` Rich Felker 2014-10-19 7:26 ` Королев Сергей 2014-10-19 9:36 ` u-wsnj 2014-10-19 10:00 ` Timo Teras 2014-10-19 17:33 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).