Re: 3.0.1pre3 - date/time discrepancy in the log

--===============0410258845==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="=-8dEzKSuP91Cfk8Vwpa1h"


--=-8dEzKSuP91Cfk8Vwpa1h
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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=20
> both ends, and have seen a date/time discrepancy in the log on the=20
> receiver. The sending machine (machineA) is in US CDT while the receiver=20
> is in US PDT. Both sender and receiver have their time set correctly.
>=20
> a contiguous snippet from the log on the receiver : (note the first=20
> 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=20
> > machineA (YY.YY.YY.YY)
> > 2008/04/02 22:18:17 [3707] rsync to backups/ssc/e_drive from machineA=20
> > (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:
>=20
> >
> > rsync -auvhzb -e 'ssh' --delete --exclude *.bkf=20
> > --partial-dir=3D.rsync-partial * root@machineB::backups/ssc/e_drive
>=20
> rsyncd.conf on receiver :
> > uid =3D 0
> > gid =3D 0
> > log file =3D /var/log/rsync.log
> > transfer logging =3D yes
> > log format =3D %o from %h %f[%M] %b bytes
> > timeout =3D 600
> > use chroot =3D yes
> >
> > [backups]
> > path =3D /usr/local/backups
> > comment =3D backups
> > write only =3D yes
> > read only =3D no
> > lock file =3D /var/run/rsyncd.lock
> > max connections =3D 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=3D4402

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 =3D /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

--=-8dEzKSuP91Cfk8Vwpa1h
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBH9RbZC+xSYN/RlfsRAn3hAJ44HdscJZwSSg4nE9K8W/ZkEqzKdgCeLeXc
OYQWMyhky28Gcf0eheTrZwY=
=WMof
-----END PGP SIGNATURE-----

--=-8dEzKSuP91Cfk8Vwpa1h--


--===============0410258845==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
--===============0410258845==--