[asterisk-bugs] [Asterisk 0014300]: [patch] zoneinfo caching causes incorrect time

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14300 
====================================================================== 
Reported By:                jamessan
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14300
Category:                   Core/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-01-21 14:05 CST
Last Modified:              2009-01-21 15:31 CST
====================================================================== 
Summary:                    [patch] zoneinfo caching causes incorrect time
Description: 
In stdtime/localtime.c, the information for time-zones are cached in a
state struct.  This caching is keyed off the name of the zone passed into
ast_tzset (using /etc/localtime if none is provided).

This is problematic since it isn't uncommon for the localtime file to be a
symlink to/copy of the actual zoneinfo file.  Therefore, if the target of
the symlink is changed to affect a change in the system's timezone,
Asterisk will not recognize the change until it is restarted.

The attached patch uses realpath(3) to attempt expanding the zone to a
full path and using that as the key instead.  This will ensure that if a
path like "/etc/localtime" or "/usr/share/zoneinfo/localtime" is being used
and is a symlink, changes in the target of the symlink will cause the
zoneinfo to be updated.

The limitations of this patch are:
1) Only notices changes when symlinks are used.  If "/etc/localtime" (or
whatever the common file is) is a copy/hardlink instead, changes won't be
noticed.  Making use of lstat(2) instead of realpath(3) may be an approach
to consider.
2) It doesn't handle the condition where zone is passed to ast_tzset and
is using a relative path and/or the zone contains a leading colon.  There's
code in tzload that determines the absolute path which could be pulled out
into a common function.  Feeding the results of that into realpath(3) would
then handle the different formats that the zone could be specified in.
====================================================================== 

---------------------------------------------------------------------- 
 (0098360) jamessan (reporter) - 2009-01-21 15:31
 http://bugs.digium.com/view.php?id=14300#c98360 
---------------------------------------------------------------------- 
1) True, changing the timezone happens infrequently, but it also means that
anything that uses Asterisk's time functions have the wrong time until
Asterisk (or the system) is restarted.
For appliances that are shipped with Asterisk and configured by the
end-user, this can mean that Asterisk-based times/logs are skewed from the
time on the rest of the system for a long time.
Making the lookup only happen for uncached entries (when the zone passed
to ast_tzset != NULL) would help but it needs to happen every time for
/etc/localtime.

2) Ah, yes, readlink(2) would be better.

If the general idea of the patch is acceptable, I can work on fixing the
two limitations I mentioned in the original report as well as the realpath
problem (although that may be fixed by addressing the first limitation).

Hmm, maybe dispatching to the standard time functions when no specific
zone has been given would be better?  As I understand it, the sole reason
for this portion of the Asterisk code is to allow things like app_voicemail
to have different timezones per-user and to specify the timezone in certain
dialplan applications.  If a specific timezone hasn't been requested, is
there a need to use these functions over the standard ones? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-21 15:31 jamessan       Note Added: 0098360                          
======================================================================