Bug 10772 - Bad time logging as daemon
Summary: Bad time logging as daemon
Status: RESOLVED INVALID
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.1
Hardware: x64 Mac OS X
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-20 00:51 UTC by Dave
Modified: 2014-08-22 14:55 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave 2014-08-20 00:51:42 UTC
When the rsync daemon logs, it fails to determine the correct time:
2014/08/18 18:47:24 [1002] connect from localhost (::1)
2014/08/18 17:47:24 [1003] rsync to dave/in-progress/data/ from dave@localhost (::1)

When I specify use chroot = false in the rsyncd.conf, it logs the time correctly:
2014/08/18 19:21:32 [1138] connect from localhost (::1)
2014/08/18 19:21:32 [1139] rsync to dave/in-progress/data/ from dave@localhost (::1)
Comment 1 Wayne Davison 2014-08-22 05:41:33 UTC
There's nothing more rsync can do about this.  It always calls a time function prior to going into the chroot, but if your OS decides to re-check the time files after that, you'll need to either supply those files in the chroot, or live with the alternate timezone.  See the rsyncd.conf manpage for how to setup a deeper dir in a chroot that doesn't allow the user to see the chrooted timezone files (e.g. "Path = /chroot/./copy-dir" allows you to create /chroot/etc that the user can't get to) and/or the exclude option (in the config file).
Comment 2 Paul Slootman 2014-08-22 14:55:03 UTC
Perhaps rsync should instead of calling a time function, first determine the offset from UTC that local time is, and then whenever a timestamp is printed first apply that delta and ignore timezones altogether after that.
Of course you lose the capability of showing the timezone (apart from [-+]HHMM) but that's not done anyway AFAIK.