3.0.1pre3 - date/time discrepancy in the log

Matt McCutchen matt at mattmccutchen.net
Thu Apr 3 17:41:48 GMT 2008


On Thu, 2008-04-03 at 09:11 -0700, Tom Cowin wrote:
> I'm using the very latest 'version 3.0.1pre3  protocol version 30', on 
> both ends, and have seen a date/time discrepancy in the log on the 
> receiver. The sending machine (machineA) is in US CDT while the receiver 
> is in US PDT. Both sender and receiver have their time set correctly.
> 
> a contiguous snippet from the log on the receiver : (note the first 
> three timestamps are correct:)
> > 2008/04/02 22:18:17 [3707] connect from machineA (YY.YY.YY.YY)
> > 2008/04/02 22:18:17 [3707] rsync allowed access on module backups from 
> > machineA (YY.YY.YY.YY)
> > 2008/04/02 22:18:17 [3707] rsync to backups/ssc/e_drive from machineA 
> > (YY.YY.YY.YY)
> > 2008/04/03 05:18:18 [3707] receiving file list
> > 2008/04/03 05:18:18 [3707] Accounting Data/
> > 2008/04/03 05:18:18 [3707] Accounting Data/eximware/
> > 2008/04/03 05:18:18 [3707] Accounting Data/eximware/QB Integration/
> > 2008/04/03 05:18:18 [3707] Accounting Data/eximware/QuPump/
> > 2008/04/03 05:18:18 [3707] Accounting Data/eximware/QuPump/Err/
> ...
> command executed on the sender:
> 
> >
> > rsync -auvhzb -e 'ssh' --delete --exclude *.bkf 
> > --partial-dir=.rsync-partial * root at machineB::backups/ssc/e_drive
> 
> rsyncd.conf on receiver :
> > uid = 0
> > gid = 0
> > log file = /var/log/rsync.log
> > transfer logging = yes
> > log format = %o from %h %f[%M] %b bytes
> > timeout = 600
> > use chroot = yes
> >
> > [backups]
> >         path = /usr/local/backups
> >         comment = backups
> >         write only = yes
> >         read only = no
> >         lock file = /var/run/rsyncd.lock
> >         max connections = 5
> Any thoughts or suggestions much appreciated....

This is probably the infamous problem where the glibc time-formatting
routine that rsync is calling can't access /etc/localtime after the
chroot and thus reverts to the default time zone, GMT.  You can read a
bit more about the issue at:

https://bugzilla.samba.org/show_bug.cgi?id=4402

Ideally we would sit down with the glibc people and figure out what
glibc ought to do in this kind of situation, but I don't know if that
will ever happen.

For now, you can work around the problem by using the new chroot+path
mode in rsync 3.0.0.  Make a chroot directory for rsync, such
as /usr/local/backups-jail , and copy /etc/localtime
to /usr/local/backups-jail/etc/localtime .  The actual module will be
at /usr/local/backups-jail/backups ; you can symlink /usr/local/backups
to that if you like.  Then change the config file to say:

	path = /usr/local/backups-jail/./backups

This tells the daemon to chroot into /usr/local/backups-jail , under
which a correct /etc/localtime file is available (avoiding the timezone
problem), and then find the module in subdirectory "backups".

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/rsync/attachments/20080403/5f08deec/attachment.bin


More information about the rsync mailing list