* 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).