On Wed 04 Apr 2007, Wakko Warner wrote: > Package: rsync > Version: 2.6.9-3 > Severity: normal > > I have one system that does an update of another via rsync when one machine > is running rsync as a daemon (IE, rsh/ssh not being used as the transport) > > The log shows this: > Apr 4 20:32:05 vegeta rsyncd[31217]: connect from nail > Apr 4 20:32:05 vegeta rsyncd[31217]: rsync on debian/pool/ from nail > Apr 5 00:32:05 vegeta rsyncd[31217]: building file list > Apr 5 00:34:44 vegeta rsyncd[31217]: sent 363012298 bytes received 17763 > bytes total size 92369457939 > > Apparently those last 2 lines are in UTC time instead of EDT time. No, it
It's a known problem upstream, and it seems to be related with how glibc handles its timezone data. If my assumptions are correct, you have this rsync module configured to do a chroot. After the chroot, rsync (or rather, glibc) can't find the timezone data, and falls back to UTC. Rsync already does its best to initialize the timezone data before the chroot, but apparently glibc wants continued access to the timezone data. On most systems the rsync approach works, only on linux the log timestamps are wrong when rsync chroots. If it's a real problem, then to workaround you need to copy the necessary timezone files to the chroot, although in practice that is probably not workable :( Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
