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
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?
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...
I don't think there's anything more that rsync can do about this issue when chroot is in effect.
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.
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.
I should add that I tested on Fedora 7 with glibc-2.6-4 .
(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?
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.
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.