[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 19 Oct 2014 13:33:35 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: do_tzset() prevents reusing the same name of a timezone
file
On Sun, Oct 19, 2014 at 01:00:29PM +0300, Timo Teras wrote:
> On Sun, 19 Oct 2014 11:36:11 +0200
> u-wsnj@...ey.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
