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.
Created attachment 6508 [details] patch
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.
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.
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.
(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.