This is a continuation of bug # 89046 which was closed prematurely with an improper resolution based on a mistaken assumption that the bug was a duplicate of another bug. Because I am not the original poster of the bug, I cannot reopen it, so I am forced to open a new bug report. Sorry for the discontinuity. The problem is that RSYNC logs report time for each transaction using a combination of GMT and Localtime instead of using either GMT or Localtime. This makes review of the logs very difficult, and compels the server user to change is local timezone to GMT to make the logs intellegible. This is (for obvious reasons) not a very good solution to the problem. Reproducible: Always Steps to Reproduce: 1. install rsync daemon 2. logs show a hybrid of GMT and localtime for each transaction 3. Actual Results: inconsistent time zone reporting by rsync. Expected Results: consistent time zone reporting by rsync. Here is a snippet from the original bug report: <snip> I have identified the same problem, but I can clarify the situation a bit. The rsyncd daemon is not consistently using localtime or GMT. instead, the first line entries are created using localtime and subsequent entries are created using GMT. My rsyncd.log files show a mixtrure of GMT timestamps and localtime timestamps. in each case, when the user logs on to perform an rsync, the initial log entry for that process ID is written in localtime, the transaction records are written in GMT, and the final log entry for that process ID is always written in GMT. is this the norm? is there some change that i can implement so that all of the timestamps use the same timezone? i've looked at the manpage and i couldn't find the answer. hopefully somebody can point out a simple oversight on my part. fyi here is a snippet from rsyncd.log: 2005/09/04 13:56:22 [7926] rsync on script from carton.764net (192.168.1.15) 2005/09/04 18:56:22 [7926] send script rsync-script-3.sh 1212 2005/09/04 18:56:22 [7926] wrote 2335 bytes read 97 bytes total size 9728 and another one: 2005/09/03 04:49:29 [1505] rsync on jackass from carton.764net (192.168.1.15) 2005/09/03 09:50:35 [1505] send jackass 2005.0/jackass-2005.0-pentium4.iso 167208960 2005/09/03 09:50:35 [1505] send jackass 2005.0/jackass-2005.0-pentium4.iso.md5 62 2005/09/03 09:50:35 [1505] send jackass rsync-jackass-2.sh 888 2005/09/03 09:50:35 [1505] wrote 167232215 bytes read 158 bytes total size 1201233200 in my case, my local timezone is GMT-5. i hope that this helps to clarify the problem. </snip> This bug was mistakenly marked as a duplicate of Bug 110038. It is not a duplicate of Bug 110038, as the remainder of the Gentoo system correctly reports system time and reported fix in the "duplicate" thread doesn't solve the problem. This is not a system-wide problem. Its specific to rsync and only to rsync. Other daemons are not to be similarly effected. in my case, i performed the following steps -- as suggested in the referenced buyg report -- but they FAILED to solve the problem: 1. i removed the symlink where /etc/localtime points to /usr/share/zoneinfo/America/Chicago. 2. i copied the timezone data file to /etc/localtime instead of creating a symlink for /etc/localtime that points to the timezone data file. 3. i restarted the server the result? nothing has changed. RSYNC continues to log using a hybrid of GMT and localtime in its logs. the problem is not being caused by the localtime symlink. when rsync chroots, the localtime data doesn't follow. one user has recommended copying the /etc/localtime data into the rsync data path FOR EVERY RSYNC MODULE be ing served. if the user does that, it seems that every rsync transfer would include a transfer of the /etc/localtime file -- this is obviously not a good solution to the problem. FWIW none of the other daemons running on the system (HTTP Servers, FTP servers, NTP servers) are similarly effected. this is a problem that is unique to rsync. so i guess its safe to say that the problem is not being caused by the use of a symlink instead of by copying the time zone data file. or am i missing something really obvious??? thanks!
*** This bug has been marked as a duplicate of 89046 ***
