samba-bugs at samba.org
2011-Jun-01 10:06 UTC
[Bug 8198] New: rsync does not set TZ variable after chroot(), which confuses logging timestamps
https://bugzilla.samba.org/show_bug.cgi?id=8198
Summary: rsync does not set TZ variable after chroot(), which
confuses logging timestamps
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at samba.org
ReportedBy: jkaluza at redhat.com
QAContact: rsync-qa at samba.org
Hi,
after chroot(), "current" timezone is changed in chrooted process
which leads
to the following output in logs:
May 29 20:00:35 nec-em12 rsyncd[9770]: connect from localhost.localdomain
(127.0.0.1)
May 29 20:00:35 nec-em12 rsyncd[9770]: rsync to my_data/ from
localhost.localdomain (127.0.0.1)
May 30 00:00:35 nec-em12 rsyncd[9770]: receiving file list
May 30 00:00:35 nec-em12 rsyncd[9770]: client/
May 30 00:00:35 nec-em12 rsyncd[9770]: client/data/
Proper time is 20:00:35.
Attached patch fixes this issue by caching current timezone and setting TZ
variable after chroot() call.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
samba-bugs at samba.org
2011-Jun-01 10:07 UTC
[Bug 8198] rsync does not set TZ variable after chroot(), which confuses logging timestamps
https://bugzilla.samba.org/show_bug.cgi?id=8198 --- Comment #1 from Jan Kaluza <jkaluza at redhat.com> 2011-06-01 10:07:01 UTC --- Created attachment 6508 --> https://bugzilla.samba.org/attachment.cgi?id=6508 patch -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Michael Tokarev
2011-Jun-01 10:15 UTC
[Bug 8198] New: rsync does not set TZ variable after chroot(), which confuses logging timestamps
01.06.2011 14:06, samba-bugs at samba.org ?????:> https://bugzilla.samba.org/show_bug.cgi?id=8198 > > Summary: rsync does not set TZ variable after chroot(), which > confuses logging timestamps > Product: rsync > Version: 3.1.0 > Platform: All > OS/Version: All > Status: NEW > Severity: normal > Priority: P5 > Component: core > AssignedTo: wayned at samba.org > ReportedBy: jkaluza at redhat.com > QAContact: rsync-qa at samba.org > > > Hi, > after chroot(), "current" timezone is changed in chrooted process which leads > to the following output in logs:> Attached patch fixes this issue by caching current timezone and setting TZ > variable after chroot() call.tzset() call before chroot should be enough for that -- that's what has always been done in chroot programs exactly for this purpose (tzset was broken in glibc at least once, but that's details). /mjt
samba-bugs at samba.org
2011-Jun-04 03:25 UTC
[Bug 8198] rsync does not set TZ variable after chroot(), which confuses logging timestamps
https://bugzilla.samba.org/show_bug.cgi?id=8198 --- Comment #2 from Matt McCutchen <matt at mattmccutchen.net> 2011-06-04 03:25:27 UTC --- The solution is a little messy and fails in the rare event that an rsync run straddles a DST change. Fundamentally, glibc is assuming that the new root directory is that of a POSIX-like system whose configuration it should observe, which is not the case. If what rsync is doing is considered a valid use case for chroot, there should be a way to advise glibc so it does not try to reload configuration. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
samba-bugs at samba.org
2011-Jun-04 03:36 UTC
[Bug 8198] rsync does not set TZ variable after chroot(), which confuses logging timestamps
https://bugzilla.samba.org/show_bug.cgi?id=8198 --- Comment #3 from Matt McCutchen <matt at mattmccutchen.net> 2011-06-04 03:36:12 UTC --- E.g., the application could call a function freeze_config(int items) to preload the configuration items it will need as indicated by the "items" bitmask and then suppress future loading of configuration. For diagnostic purposes, glibc functions could fail if they use configuration items whose necessity was not declared to freeze_config, even if the application was lucky enough to have loaded the items for another reason. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
samba-bugs at samba.org
2011-Jun-04 16:37 UTC
[Bug 8198] rsync does not set TZ variable after chroot(), which confuses logging timestamps
https://bugzilla.samba.org/show_bug.cgi?id=8198
Wayne Davison <wayned at samba.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #4 from Wayne Davison <wayned at samba.org> 2011-06-04
16:37:15 UTC ---
I do think that if the chroot call doesn't find a new timezone setup, that
it
should leave things alone. That is how things have always worked before, and
supports minimal chroot areas better. So, fundamentally, I think this is a
glibc issue.
A user should be able to work around this by setting their own TZ string before
starting up the daemon. For instance, I have sometimes used this TZ for other
purposes:
export TZ=PST8PDT
Note that this setting fully supports daylight savings time changes. If rsync
were tweaked to set a TZ var, it would be nice if it could construct such an
all-encompassing export, but that does seem rather complex to try to code up,
and is probably more trouble than it's worth.
So, I'm not particularly liking the TZ idea, especially since a user
affected
by a buggy libc has an easy way to configure this externally to rsync.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
samba-bugs at samba.org
2011-Jun-04 18:04 UTC
[Bug 8198] rsync does not set TZ variable after chroot(), which confuses logging timestamps
https://bugzilla.samba.org/show_bug.cgi?id=8198 --- Comment #5 from Matt McCutchen <matt at mattmccutchen.net> 2011-06-04 18:04:35 UTC --- (In reply to comment #4)> I do think that if the chroot call doesn't find a new timezone setup, that it > should leave things alone. That is how things have always worked before, and > supports minimal chroot areas better.The chroot call doesn't do anything with timezones. The functions that make use of the timezone are periodically checking /etc/localtime to respond to system configuration changes. What you suggest fails if the in-chroot module path is empty and there happens to be an /etc/localtime file in the module, or if another application chroots into a POSIX-like system that omits /etc/localtime with the intent that the default be used. I maintain that the right solution is for the application to tell glibc whether to freeze the configuration upon chroot. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.