Bug 4402 - Incorrect time logged with glibc 2.5 inside chroot area
Incorrect time logged with glibc 2.5 inside chroot area
Status: RESOLVED WONTFIX
Product: rsync
Classification: Unclassified
Component: core
2.6.9
Other Windows XP
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-18 07:14 UTC by Kilburn Abrahams
Modified: 2008-04-03 12:27 UTC (History)
1 user (show)

See Also:


Attachments
Chroot + timezone test program (583 bytes, text/x-csrc)
2007-07-18 13:41 UTC, Matt McCutchen
no flags Details
Test program #2 (580 bytes, text/x-csrc)
2007-07-21 09:13 UTC, Matt McCutchen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kilburn Abrahams 2007-02-18 07:14:20 UTC
rsync 2.6.9 fixed the time logging. I upgraded to glibc 2.5. The time loggin problem again started.  Problem still persists after a recompile.

Using Gentoo 2.6.19 + glibc 2.5.

From logs (with glibc 2.3 and rsync 2.6.9)

Time: Mon Feb 12 15:46:43 EST 2007
2007/02/12 04:46:43 [16263] receiving file list
2007/02/12 04:46:43 [16263] sent 85 bytes  received 393 bytes  total size 244652

It should be (with glibc 2.5 and rsync 2.6.9)
2007/02/12 15:46:43 [16263] receiving file list
2007/02/12 15:46:43 [16263] sent 85 bytes  received 393 bytes  total size 244652

I also compiled the latest CVS version, and it also shows the incorrect logged time.

I have to set chroot = no, for the time to display correctly.

Also confirmed on Fedora system with glibc 2.5
Comment 1 Wayne Davison 2007-02-18 08:18:51 UTC
Isn't this a glibc bug that needs to be fixed by them, not rysnc?

Did you try setting the TZ environment variable in the environment of your rsync daemon to see if that helps the latest strftime() output correctly?
Comment 2 John Van Essen 2007-03-23 23:52:04 UTC
I agree that this problem does need to be addressed by the glibc maintainers.

This problem was also reported on the rsync list on 2/12.  Matt confirmed the problem, supplied an strace, and summarized:

> I can reproduce the time problem on my computer with Fedora Core 6 and
> glibc 2.5.  Attached is a file of excerpts from the daemon's strace.
> It looks like glibc is trying to be clever by statting /etc/localtime
> on every call to strftime in case the time zone setting has changed.
> If /etc/localtime disappears, glibc reverts to GMT.

This Aug 2004 bug report seems to have triggered the change to tzset.c that eventually manifested itself in this glibc 2.5 problem:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=154

But there were additional changes in Sep 2004 to tzfile.c regarding rechecking if the same timezone file was in use.

The source tree is here if someone cares to further examine them and eventually file a bug report w/redhat about this getting screwed up if chroot is used:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/time/?cvsroot=glibc

... and also remind them to note in the source that the maintainers need to be aware of chroot ramifications when making future source changes.

But I don't quite understand why these 2+ yead-old changes didn't cause problems until recently with glibc 2.5...
Comment 3 Wayne Davison 2007-07-14 14:50:19 UTC
I don't think there's anything more that rsync can do about this issue when chroot is in effect.
Comment 4 Chris Smith 2007-07-18 12:40:00 UTC
Is there anything to be done about this?
Problem still exists today with 2.6.9 and both glibc-2.5 and glibc-2.6.
Comment 5 Matt McCutchen 2007-07-18 13:41:58 UTC
Created attachment 2829 [details]
Chroot + timezone test program

I wrote a small test program in C to try to reproduce the problem without rsync (attached).  Strangely enough, none of the several variations of the program that I tried exhibit the problem, while an rsync daemon I set up does.  I wonder what rsync is doing differently.
Comment 6 Matt McCutchen 2007-07-18 13:44:54 UTC
I should add that I tested on Fedora 7 with glibc-2.6-4 .
Comment 7 Wayne Davison 2007-07-18 17:24:39 UTC
(In reply to comment #5)
> Strangely enough, none of the several variations of the program
> that I tried exhibit the problem, while an rsync daemon I set up does.

Did you try using localtime() instead of localtime_r()?  I wonder if the latter would help rsync?

Did you try forking after the chroot?

Comment 8 Matt McCutchen 2007-07-21 09:13:07 UTC
Created attachment 2836 [details]
Test program #2

(In reply to comment #7)
> Did you try using localtime() instead of localtime_r()?  I wonder if the latter
> would help rsync?
> 
> Did you try forking after the chroot?

I changed the program to use localtime() and forked both before and after the chroot (attached).  Nevertheless, all four processes gave the correct time.  This is really puzzling.  I suppose I will have to butcher a copy of the rsync source code down to a test program little by little and see when the inaccuracy goes away.
Comment 9 Matt McCutchen 2008-04-03 12:27:28 UTC
Note that the chroot+path mode added in rsync 3.0.0 can be used to work around this problem by having the daemon chroot into a directory containing a correct /etc/localtime file and putting the module somewhere inside that directory.