Paul Slootman wrote: > 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.
I just checked, it is doing a chroot. I don't think it really matters since this isn't internet accessible. > 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 :( -- Lab tests show that use of micro$oft causes cancer in lab animals Got Gas??? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
