Bug 8198 - rsync does not set TZ variable after chroot(), which confuses logging timestamps
rsync does not set TZ variable after chroot(), which confuses logging timestamps
Status: RESOLVED WONTFIX
Product: rsync
Classification: Unclassified
Component: core
3.1.0
All All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-01 10:06 UTC by Jan Kaluza
Modified: 2011-06-04 18:04 UTC (History)
0 users

See Also:


Attachments
patch (1.19 KB, patch)
2011-06-01 10:07 UTC, Jan Kaluza
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kaluza 2011-06-01 10:06:18 UTC
Hi,
after chroot(), "current" timezone is changed in chrooted process which leads to the following output in logs:

May 29 20:00:35 nec-em12 rsyncd[9770]: connect from localhost.localdomain
(127.0.0.1) 
May 29 20:00:35 nec-em12 rsyncd[9770]: rsync to my_data/ from
localhost.localdomain (127.0.0.1) 
May 30 00:00:35 nec-em12 rsyncd[9770]: receiving file list 
May 30 00:00:35 nec-em12 rsyncd[9770]: client/ 
May 30 00:00:35 nec-em12 rsyncd[9770]: client/data/

Proper time is 20:00:35.

Attached patch fixes this issue by caching current timezone and setting TZ variable after chroot() call.
Comment 1 Jan Kaluza 2011-06-01 10:07:01 UTC
Created attachment 6508 [details]
patch
Comment 2 Matt McCutchen 2011-06-04 03:25:27 UTC
The solution is a little messy and fails in the rare event that an rsync run straddles a DST change.

Fundamentally, glibc is assuming that the new root directory is that of a POSIX-like system whose configuration it should observe, which is not the case.  If what rsync is doing is considered a valid use case for chroot, there should be a way to advise glibc so it does not try to reload configuration.
Comment 3 Matt McCutchen 2011-06-04 03:36:12 UTC
E.g., the application could call a function freeze_config(int items) to preload the configuration items it will need as indicated by the "items" bitmask and then suppress future loading of configuration.  For diagnostic purposes, glibc functions could fail if they use configuration items whose necessity was not declared to freeze_config, even if the application was lucky enough to have loaded the items for another reason.
Comment 4 Wayne Davison 2011-06-04 16:37:15 UTC
I do think that if the chroot call doesn't find a new timezone setup, that it should leave things alone.  That is how things have always worked before, and supports minimal chroot areas better.  So, fundamentally, I think this is a glibc issue.

A user should be able to work around this by setting their own TZ string before starting up the daemon.  For instance, I have sometimes used this TZ for other purposes:

export TZ=PST8PDT

Note that this setting fully supports daylight savings time changes.  If rsync were tweaked to set a TZ var, it would be nice if it could construct such an all-encompassing export, but that does seem rather complex to try to code up, and is probably more trouble than it's worth.

So, I'm not particularly liking the TZ idea, especially since a user affected by a buggy libc has an easy way to configure this externally to rsync.
Comment 5 Matt McCutchen 2011-06-04 18:04:35 UTC
(In reply to comment #4)
> I do think that if the chroot call doesn't find a new timezone setup, that it
> should leave things alone.  That is how things have always worked before, and
> supports minimal chroot areas better.

The chroot call doesn't do anything with timezones.  The functions that make use of the timezone are periodically checking /etc/localtime to respond to system configuration changes.

What you suggest fails if the in-chroot module path is empty and there happens to be an /etc/localtime file in the module, or if another application chroots into a POSIX-like system that omits /etc/localtime with the intent that the default be used.  I maintain that the right solution is for the application to tell glibc whether to freeze the configuration upon chroot.